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As organizagées percebem que os dados de valor atuam como um ativo 
estratégico para varias iniciativas relacionadas aos negdcios, como o aumento 
da receita, a melhoria da experiéncia do cliente, a operagao eficiente ou a 
melhoria de um produto ou servigo. No entanto, 0 acesso e o gerenciamento de 
dados para essas iniciativas tem se tornado cada vez mais complexos. A maior 
parte da complexidade surgiu com a explosao de volumes e tipos de dados, 
com organizagdes acumulando uma estimativa de 80% dos dados em formato 
nao estruturado e semiestruturado. A medida que a coleta de dados continua 
aumentando, 73% deles nao sao usados para analise ou tomada de decisao. 
Para tentar diminuir essa porcentagem e tornar os dados mais utilizaveis, as 
equipes de engenharia de dados sao responsaveis por criar pipelines de dados 
para entrega-los de forma eficiente e confiadvel. Mas 0 processo de criagao 
desses pipelines de dados complexos traz uma série de dificuldades: 


Para colocar dados em um data lake, os engenheiros de dados sao 
obrigados a gastar muito tempo programando tarefas de ingestao 
de dados repetitivas 


e Uma vez que as plataformas de dados mudam continuamente, 
os engenheiros de dados gastam tempo construindo e mantendo e, 
em seguida, reconstruindo, uma infraestrutura escalavel complexa. 


* A medida que o pipeline de dados se torna mais complexo, os engenheiros 
de dados s&o obrigados a encontrar ferramentas confiaveis para 
orquestrar esses pipelines. 


* Com acrescente importancia dos dados em tempo real, sdo necessarios 
pipelines de dados de baixa laténcia, que sao ainda mais dificeis de 
construir e manter. 


¢ Por fim, com todos os pipelines escritos, os engenheiros de dados precisam 
se concentrar constantemente no desempenho, ajustando pipelines e 
arquiteturas para atender aos SLAs. 
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Como a Databricks pode ajudar? 


Com a Plataforma Databricks Lakehouse, os engenheiros de dados tém acesso a 
uma solugao de engenharia de dados de ponta a ponta para ingerir, transformar, 
processar, agendar e entregar dados. A Plataforma Lakehouse automatiza a 
complexidade de construir e manter pipelines e executar cargas de trabalho ETL 
diretamente em um data lake para que os engenheiros de dados possam se 
concentrar na qualidade e confiabilidade para gerar insights valiosos. 
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One platform to support multiple personas 
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BI & Data Data Data Data 
Warehousing Engineering Streaming Science & ML 


Unity Catalog 


Fine-grained governance for data and Al 


Delta Lake 


Data reliability and performance 


Cloud Data Lake 


All Raw Data (Logs, Texts, Audio, Video, Images) 


Figura 1 
A Plataforma Databricks Lakehouse unifica seus dados, analises e [A em uma plataforma comum para todos os seus casos 
de uso de dados 
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Principais diferenciais para engenharia de dados 
bem-sucedida com Databricks 


Ao simplificar uma arquitetura de lakehouse, os engenheiros de dados precisam 
de uma abordagem pronta e de nivel empresarial para criar pipelines de dados. 
Para ter sucesso, uma equipe de solugées de engenharia de dados deve adotar 
estes oito principais recursos diferenciais: 


Ingestao de dados em escala 

Com a capacidade de ingerir petabytes de dados com esquemas de evolugao 
automatica, os engenheiros de dados podem fornecer dados rapidos, confiaveis, 
escalaveis e automaticos para analise, ciéncia de dados ou machine learning. 
Isso inclu: 


e Processar dados de forma progressiva e eficiente a medida que chegam 
de arquivos ou fontes de streaming como Kafka, DBMS e NoSQL 


¢ Inferir automaticamente o esquema e detectar alteragdes de coluna para 
formatos de dados estruturados e nao estruturados 


e Rastrear dados de forma automatica e eficiente 4 medida que eles chegam 
sem intervengao manual 


¢ Evitar a perda de dados resgatando colunas de dados 
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Pipelines de ETL declarativos 

Os engenheiros de dados podem reduzir o tempo e o esfor¢go de desenvolvimento 
e se concentrar na implementagao de ldgica de negocios e verificagées de 
qualidade de dados no pipeline de dados usando SQL ou Python. Isso pode ser 
alcangado por meio de: 


e Uso do desenvolvimento declarativo orientado por intengao para simplificar 
o “como” e definir “o que” resolver 


¢ Criagao automatica de linhagem de alta qualidade e gerenciamento 
de dependéncias de tabela em todo o pipeline de dados 


° Verificagaéo automatica de dependéncias ausentes ou erros de sintaxe 
e gerenciamento de recuperagao do pipeline de dados 


Processamento de dados em tempo real 

Permita que engenheiros de dados ajustem a laténcia de dados com controles 
de custo sem a necessidade de conhecer o processamento de fluxo complexo 
ou implementar l6gica de recuperagao. 


e Evite lidar com fontes de dados de streaming em tempo real e em batch 
separadamente 


e Execute cargas de trabalho de pipeline de dados em compute clusters 
baseados em Apache Spark™ flexiveis e automaticamente provisionados 
para escala e desempenho 


¢ Elimine a necessidade de gerenciar a infraestrutura e concentre-se 
na légica de negécios para casos de uso downstream 
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Orquestrac¢ao unificada de fluxo de trabalho de dados 
databricks Orquestragao simples, clara e confiavel de tarefas de processamento de dados 
See Cloud | Uskonoee Sevier para pipelines de dados, analises e machine learning com a capacidade de 


Storage 


i Se ea eal executar multiplas tarefas nao interativas como um grafo aciclico dirigido 
a” ae (DAG) em clusters de compute Databricks. Orquestre tarefas de qualquer tipo 
| iiitebleoy ier (SQL, Python, JARs, Notebooks) em um DAG usando Databricks Workflows, uma 
a cae ferramenta de orquestragao incluida no lakehouse sem necessidade de manter 
oat: Mamenarce ""Ofes igrantes ou pagar por um servico de orquestragao externo. 
Real-Time Operational 
‘S 8 ° Crie e gerencie facilmente multiplas tarefas com dependéncias via UI, 
aes API ou do seu IDE 


Photon for lightning-fast data processing 


¢ Tenha total observabilidade de todas as execugées de fluxo de trabalho 


@ CONFLUENT 


Unity Catalog for data governance and sharing 


a A ee a e receba alertas quando as tarefas falharem para solugao de problemas 
rapida e reparo e execugao eficientes 


¢ Aproveite a alta confiabilidade do tempo de atividade de 99,95% 


Figura 2 ¢ Use clusters de otimizagaéo de desempenho que paralelizam jobs 


Um conjunto unificado de ferramentas para processamento de dados em tempo real e minimizam o movimento de dados com reutilizagao de clusters 


Validagao e monitoramento da qualidade dos dados 

Melhore a confiabilidade dos dados em todo o data lakehouse para que 
as equipes de dados possam confiar nas informagées para iniciativas de 
downstream através de: 


¢ Definigao de controles de integridade e qualidade de dados dentro 
do pipeline com expectativas de dados definidas 


¢ Abordagem de erros de qualidade de dados com politicas predefinidas 
(falha, queda, alerta, quarentena) 


¢ Alavancagem das métricas de qualidade de dados que sao capturadas, 
rastreadas e comunicadas para todo o pipeline de dados 
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Recuperagao automatica e tolerante a falhas 

Manuseie erros transit6rios e recupere-se das condi¢ées de erro mais comuns 
que ocorrem durante a operagao de um pipeline com recuperagao automatica 
rapida e escalonavel, que inclui: 


e Mecanismos tolerantes a falhas para recuperar consistentemente o estado 
dos dados 


¢ Capacidade de rastrear automaticamente o progresso da fonte com 
pontos de verificagao 


e Capacidade de recuperar e restaurar automaticamente o estado do 
pipeline de dados 


Observabilidade do pipeline de dados 

Monitore o status geral do pipeline de dados de um painel de grafico de fluxo de 
dados e monitore visualmente a integridade do pipeline de ponta a ponta para 
desempenho, qualidade e laténcia. Os recursos de observabilidade do pipeline 
de dados incluem: 


e Um diagrama de linhagem de alta qualidade e alta fidelidade que fornece 
visibilidade sobre como os dados fluem para analise de impacto 


e Registro granular com desempenho e status do pipeline de dados em 
nivel de linha 


e Monitoramento continuo dos trabalhos de pipeline de dados para garantir 
operagao continua 
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Implementagées e operagées automaticas 

Garanta uma entrega confiavel e previsivel de dados para casos de uso de 
fungées analiticas e machine learning, permitindo implementag6es e reversdes 
de pipeline de dados faceis e automaticas para minimizar 0 tempo de 
inatividade. Os beneficios incluem: 


¢ Implementagao completa, parametrizada e automatizada para a entrega 
continua de dados 


e Orquestragao, testes e monitoramento de ponta a ponta da implementacgao 
do pipeline de dados em todos os principais provedores de nuvem 


Migragoes 
Acelerar e reduzir os riscos da jornada de migragao para o lakehouse, seja 
de sistemas legados no local ou de servigos de nuvens distintos. 


O processo de migragaéo comega com uma descoberta e avaliagao detalhadas 
para obter insights sobre as cargas de trabalho da plataforma legada e estimar 

a migragao, bem como os custos de consumo da plataforma Databricks. Obtenha 
ajuda com a arquitetura alvo e como a pilha de tecnologia atual € mapeada para 
Databricks, seguida de uma implementagao em fases com base em prioridades 

e necessidades de negocios. Por toda parte nesta jornada, as empresas 

podem aproveitar: 


e Ferramentas de automagao da Databricks e de suas parcerias de ISV 


* Sls globais e/ou regionais que criaram solugées de migragao para 
o Brickbuilder 


¢ Treinamento e servicos profissionais Databricks 


Esta € a abordagem recomendada para uma migragaéo bem-sucedida, em que 
os clientes observaram uma redugao de custos de 25 a 50% e um tempo de 
retorno duas a trés vezes mais rapido para seus casos de uso. 
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Governanga unificada 

Com 0 Unity Catalog, as equipes de engenharia e governanga de dados 

se beneficiam de um catalogo de dados para toda a empresa com uma 
interface Unica para gerenciar permiss6es, centralizar a auditoria, rastrear 
automaticamente a linhagem de dados até o nivel da coluna e compartilhar 
dados entre plataformas, nuvens e regides. Beneficios: 


e Descubra todos os seus dados em um so lugar, nao importa onde estejam, 
e gerencie centralmente permissdes de acesso refinadas usando uma 
interface ANSI baseada em SQL 


¢ Aproveite a linhagem de dados automatizada em nivel de coluna para 
realizar analises de impacto de quaisquer alteragdes de dados no pipeline 
e conduzir analises de causa raiz de quaisquer erros no pipeline de dados 


e Audite centralmente os direitos e o acesso aos dados 


¢ Compartilhe dados entre nuvens, regides e plataformas de dados, mantendo 
uma Unica cépia dos seus dados no armazenamento em nuvem 


Um rico ecossistema de solugées de dados 

A Plataforma Databricks Lakehouse é construida em tecnologia de cédigo 
aberto e usa padr6ées abertos para que as principais solugdes de dados possam 
ser aproveitadas com qualquer coisa que vocé crie no lakehouse. Uma grande 
colegao de parcerias tecnolégicas torna facil e simples integrar a tecnologia na 
qual vocé confia ao migrar para Databricks e saber que vocé nao esta preso a 
uma pilha fechada de tecnologia de dados. 
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A Plataforma Databricks Lakehouse se integra a uma grande colecao de tecnologias 
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Conclusao 


A medida que as organizagées se esforgam para se tornarem orientadas por 
dados, a engenharia de dados € um ponto focal para o sucesso. Para fornecer 
dados confiaveis, os engenheiros de dados nao precisam gastar tempo 
desenvolvendo e mantendo manualmente um ciclo de vida ETL de ponta a 
ponta. As equipes de engenharia de dados precisam de uma maneira eficiente e 
escalavel de simplificar o desenvolvimento de ETL, melhorar a confiabilidade dos 
dados e gerenciar as operagoes. 


Conforme descrito, os oito principais recursos de diferenciagao simplificam o 
gerenciamento do ciclo de vida de ETL, automatizando e mantendo todas as 
dependéncias de dados, aproveitando os controles de qualidade integrados 
com monitoramento e fornecendo visibilidade profunda das operagées de 
pipeline com recuperagao automatica. As equipes de engenharia de dados 
agora podem se concentrar na criagao facil e rapida de pipelines de dados 
prontos para produgao de ponta a ponta e confiaveis usando apenas SQL ou 
Python em batch e streaming que fornecem dados de alto valor para fungdes 
analiticas, ciéncia de dados ou machine learning. 
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Siga as praticas recomendadas comprovadas 


Na préxima segao, descrevemos as praticas recomendadas para casos de uso 
de ponta a ponta da engenharia de dados extraidos de exemplos do mundo 
real. Da ingestao e do processamento em tempo real até fungdes analiticas 

e machine learning, vocé aprendera como converter dados brutos em dados 
acionaveis. 


A medida que vocé explora o restante deste guia, pode encontrar conjuntos de 
dados e exemplos de cédigo nos varios aceleradores de solugées Databricks, 
para que vocé possa colocar a mao na massa enquanto explora todos os 
aspectos do ciclo de vida dos dados na Plataforma Databricks Lakehouse. 


Comece a experimentar esses 
notebooks Databricks gratuitos. 


SECAO 


databricks 
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SECAO 2.1 


As 5 principais dicas de desempenho da Databricks 


de BRYAN SMITH e ROB SAKER 
10 de margo de 2022 


Como arquitetos de solugées, trabalhamos em estreita colaboragao com os 
clientes todos os dias para ajuda-los a obter o melhor desempenho do seu 
trabalho no Databricks, e muitas vezes acabamos por dar o mesmo conselho. 


Nao é€ incomum conversar com um cliente e obter o dobro, o triplo ou até mais 


desempenho com apenas alguns ajustes. Qual € o segredo? Como fazemos 
isso? Aqui estao as cinco principais coisas que vemos que podem causar um 
enorme impacto no desempenho que os clientes obtém do Databricks. 


Aqui esta um resumo: 


e Use clusters maiores. Pode parecer 6bvio, mas este é 0 problema numero 
um que vemos. Na verdade, nao é mais caro usar um cluster grande para 
uma carga de trabalho do que usar um cluster menor. E apenas mais 
rapido. Se ha algo que vocé deveria aprender com estes artigos, é isso. 
Leia a segao 1. Sério. 


e Use o Photon, 0 novo mecanismo de execugao super-rapido da Databricks. 


Leia a segao 2 para saber mais. Vocé nao vai se arrepender. 
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e Limpe suas configuragées. Configuragées transferidas de uma versao do 
Apache Spark™ para outra podem causar problemas enormes. Limpe tudo! 
Leia a secao 3 para saber mais. 


¢ Use o Delta Caching. Ha uma boa chance de vocé nao estar usando 0 cache 
corretamente, se é que esta usando. Consulte a secao 4 para saber mais. 


¢ Cuidado com a avaliagao preguigosa. Se isso nao significa nada para vocé 
e vocé esta escrevendo cédigo Spark, va para a secao 5. 


¢ Dica bénus! O design da tabela é muito importante. Abordaremos isso 
em blogs futuros, mas, por enquanto, confira o guia sobre as praticas 
recomendadas do Delta Lake. 


1. Dé poténcia aos seus clusters! 


Este é 0 erro numero um que os clientes cometem. Muitos clientes criam 
pequenos clusters de dois workers com quatro nucleos cada, e leva uma 
eternidade para fazer qualquer coisa. A preocupagao € sempre a mesma: nao 
querem gastar muito dinheiro em clusters maiores. O problema € 0 seguinte: 
na verdade, nao é mais caro usar um cluster grande para uma carga de 
trabalho do que usar um cluster menor. E apenas mais rapido. 
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O segredo € que vocé esta alugando o cluster pela duragao da carga de trabalho. 
Portanto, se vocé ativar esses dois clusters worker e levar uma hora, estara pagando 
por esses workers pela hora inteira. Mas se vocé ativar quatro clusters worker 

e levar apenas meia hora, na verdade, o custo sera o mesmo. E essa tendéncia 
continua enquanto houver trabalho suficiente para os clusters realizarem. 


Aqui esta um cenario hipotético que ilustra esse ponto: 


Nd&mero workers Custoporhora Duragdo da carga de trabalho (horas) Custo da carga de trabalho 


1 US$ 1 2 US$2 
2 US$ 2 1 US$ 2 
4 US$ 4 0,5 US$ 2 
8 US$ 8 0,25 US$ 2 


Observe que o custo total da carga de trabalho permanece 0 mesmo, enquanto 

o tempo real necessario para a execugao do job cai significativamente. Aumente 
as especificagées dos clusters do Databricks e acelere suas cargas de trabalho 

sem gastar mais dinheiro. Nao da para ser mais simples do que isso. 


2. Use o Photon 


Nossos colegas da engenharia reescreveram 0 mecanismo de execugao Spark 
em C++ e o apelidaram de Photon. Os resultados sao impressionantes! 
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Relative Speedup to DBR 2.1 by DBR version 
Higher is better 


Relative Speedup to DBR 2.1 


DBR version (TPC-DS ITB 10 x i3.x!) 


Além das melhorias 6ébvias devido a execugao do mecanismo em cédigo nativo, 
eles também fizeram uso de recursos de desempenho em nivel de CPU e melhor 
gerenciamento de memiéria. Além disso, reescreveram 0 cédigo Parquet em C++. 
Isso também faz com que escrever para o Parquet e o Delta (com base no Parquet) 
seja super-rapido. 


Mas também sejamos claros sobre 0 que o Photon esta acelerando. Ele melhora 
a velocidade de computagao para quaisquer fungdes ou operacées integradas, 
bem como grava em Parquet ou Delta. Joins? Sim! Agregacées? Claro! ETL? 
Também! Aquela UDF (fungaéo definida pelo usuario) que vocé escreveu? Poxa, 
mas nao vai ser Util nisso. O trabalho que passa a maior parte do tempo lendo 
um antigo banco de dados local? Também nao vai ajudar nisso, infelizmente. 
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A boa noticia é que ele ajuda onde pode. Portanto, mesmo que parte do seu 
trabalho nao possa ser acelerada, as outras partes serao. Além disso, a maioria 
dos trabalhos sao escritos com operagées nativas e passam muito tempo 
escrevendo para Delta, e o Photon ajuda muito nisso. Experimente. Vocé pode 
se impressionar com os resultados! 


3. Limpe as configuragoes antigas 


Sabe aquelas configuragdes do Spark que vocé vem carregando de versao em 
versao e ninguém sabe mais o que elas fazem? Elas podem nao ser inofensivas. 
Vimos jobs passarem de horas para minutos simplesmente limpando configuragées 
antigas. Pode ter havido uma peculiaridade em uma versao especifica do Spark, um 
ajuste de desempenho que nao envelheceu bem ou algo retirado de alguns blogs em 
algum lugar que nunca fez sentido. No minimo, vale a pena revisar as configuragées 
do Spark se vocé estiver nessa situagao. Muitas vezes, as configuragédes-padrao 
sao as melhores, e elas estao ficando cada vez melhor. Suas configuragé6es podem 
estar atrasando vocé. 


4. O Delta Cache é seu amigo 


Isso pode parecer 6bvio, mas vocé ficaria surpreso com a quantidade de pessoas 
que nao estao usando o Delta Cache, que carrega dados do armazenamento em 
nuvem (S3, ADLS) e os mantém nos SSDs worker para acesso mais rapido. 
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Se vocé estiver usando Databricks SQL Endpoints, vocé esta com sorte. Eles 
tém cache ativado por padrao. Na verdade, recomendamos usar a tabela 
CACHE SELECT * FROM para pré-carregar suas tabelas principais ao iniciar um 
endpoint. Isso garantira velocidades extremamente rapidas para qualquer query 
nessas tabelas. 


Se vocé estiver usando clusters regulares, use a série i3 na Amazon Web 
Services (AWS), a série L ou a série E no Azure Databricks ou n2 no GCP. Todos 
eles terao SSDs rapidos e cache habilitados por padrao. 


Claro, sua milhagem pode variar. Se vocé estiver fazendo BI, o que envolve ler 
as mesmas tabelas repetidamente, o armazenamento em cache oferece um 
impulso incrivel. No entanto, se vocé simplesmente ler uma tabela uma vez 

e escrever os resultados como em algum job ETL, podera nao obter muitos 
beneficios. Vocé conhece seu trabalho melhor do que ninguém. Va em frente 
e conquiste. 


Reading from Cloud Storage vs Delta Cache 


80 


60 


Values read per core per second (in millions) 
o 


Cloud Storage Delta Cache 
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5. Cuidado com a avaliagao lenta 


Se vocé é analista de dados ou cientista de dados apenas usando SQL ou fazendo 
BI, vocé pode pular esta segao. No entanto, se vocé estiver trabalhando em 
engenharia de dados e escrevendo pipeline ou processando usando Databricks/ 
Spark, continue lendo. 


Ao escrever cédigo Spark como select, groupBy, filter, etc., vocé esta realmente 
construindo um plano de execugao. Vocé notara que o cédigo retorna quase 
imediatamente ao executar essas fungées. Isso porque, na verdade, ele nao esta 
fazendo nenhum calculo. Portanto, mesmo que vocé tenha petabytes de dados, 
ele retornara em menos de um segundo. 


No entanto, depois de escrever seus resultados, vocé percebera que leva mais 
tempo. Isso se deve a avaliagao lenta. S6 quando vocé tenta exibir ou gravar 
resultados € que seu plano de execugao é realmente executado. 


# Construa um plano de execugao 
# Isso retorna em menos de um segundo, mas nao funciona 
df2 = (df 
-join(...) 
-select(...) 
-filter(...) 
) 


# Agora execute o plano de execugdéo para obter resultados 
df2.display() 
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No entanto, ha um problema aqui. Cada vez que vocé tenta exibir ou escrever 
resultados, o plano de execugao é executado novamente. Vejamos 0 mesmo 
bloco de cédigo, mas estenda-o e faga mais algumas operacées. 


# Construa um plano de execugao 
# Isso retorna em menos de um segundo, mas nao funciona 
df2 = (df 

-join(...) 

-select(...) 

-filter(...) 


) 


# Agora execute o plano de execugédo para obter resultados 
df2.display() 


# Infelizmente, isso executarad o plano novamente, incluindo filtragem, 
combinagaéo, etc. 
df2.display() 


# Entdo sera que... 
df£2.count() 
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O desenvolvedor deste cédigo pode muito bem estar pensando que esta 
apenas imprimindo os resultados trés vezes, mas 0 que na verdade ele esta 
fazendo é iniciar o mesmo processamento trés vezes. Opa. Isso € muito trabalho 
extra. Este 6 um erro muito comum que cometemos. Enta&o, por que existe uma 
avaliagao lenta e o que fazemos a respeito? 


Resumindo, 0 processamento com avaliagao lenta € muito mais rapido do que 
sem ela. O Databricks/Spark analisa o plano de execugao completo e encontra 
oportunidades de otimizagao que podem reduzir o tempo de processamento 
em ordens de magnitude. Isso é é6timo, mas como evitamos o calculo extra? A 
resposta é bastante direta: salve os resultados do calculo que vocé vai reutilizar. 


Vejamos o mesmo bloco de cédigo novamente, mas desta vez vamos evitar 
recalculo: 


# Construa um plano de execugao 
# Isso retorna em menos de um segundo, mas nao funciona 
df2 = (df 
-join(...) 
-select(...) 
-filter(...) 
) 


# salve 
df2.write.save(path) 


# carregue de volta 
df3 = spark.read.load(path) 


# agora use 
df3.display() 


# nao esta mais fazendo nenhum calculo extra. Sem jungoes, filtros, etc. 
Ja esta feito e salvo 


df3.display() 


# nem é isso 
df3.count() 
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Funciona especialmente bem quando o Delta Caching esta ativado. Resumindo, 
vocé se beneficia muito da avaliagao lenta, mas é algo em que muitos clientes 
tropegam. Portanto, esteja ciente de sua existéncia e salve os resultados que 
vocé reutiliza para evitar calculos desnecessarios. 


Comece a experimentar com estes 
notebooks gratuitos da Databricks. 
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SECAO 2.2 


Como criar um perfil do PySpark 


de XINRONG MENG, TAKUYA UESHIN, HYUKJIN KWON e ALLAN FOLTING 
6 de outubro de 2022 


No Apache Spark™, as APIs Python declarativas sAo compativeis com cargas 

de trabalho de big data. Elas sAo poderosas o suficiente para lidar com os 
casos de uso mais comuns. Além disso, os UDFs do PySpark oferecem mais 
flexibilidade, pois permitem que os usuarios executem cddigo Python arbitrario 
no mecanismo Apache Spark™. Os usuarios s6 precisam indicar “o que fazer”; O 
PySpark, como uma sandbox, encapsula “como fazer”. Isso torna o PySpark mais 
facil de usar, mas pode ser dificil identificar gargalos de desempenho e aplicar 
otimizagées personalizadas. 


Para resolver a dificuldade mencionada acima, o PySpark € compativel com 
varias ferramentas de criagao de perfil, todas baseadas em cProfile, uma das 
implementagdes-padrao do criador de perfil do Python. Os PySpark Profilers 
fornecem informagdes como o numero de chamadas de fungao, o tempo total 
gasto em uma determinada fungao e 0 nome do arquivo, bem como o numero 
da linha para ajudar na navegacao. Essas informagoes sao essenciais para expor 
lacunas em seus programas PySpark e permitir que vocé tome decisdes de 
melhoria de desempenho. 
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Perfil do driver 


As aplicagées PySpark sao executadas como conjuntos independentes de 
processos em clusters, coordenados pelo objeto SparkContext no programa 

do driver. Do lado do driver, PySpark € um processo Python regular; portanto, 
podemos tragar o perfil dele como um programa Python normal usando cProfile 
conforme ilustrado abaixo: 


import cProfile 


with cProfile.Profile() as pr: 
# Seu cddigo 


pr.print_stats() 


Perfil de worker 


Executores sao distribuidos em nés worker nos clusters, 0 que introduz 
complexidade porque precisamos agregar perfis. Alem disso, um processo 
worker Python é gerado por executor para execugao do PySpark UDF, 0 que 
torna o perfil mais complexo. 
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O criador de perfil UDF, introduzido no Spark 3.3, supera todos esses obstaculos 
e se torna uma ferramenta importante para criar perfil de workers para 
aplicagdes PySpark. Vamos ilustrar como usar o criador de perfil UDF com um 
exemplo simples de Pandas UDF. 


Primeiro, um DataFrame do PySpark com 8.000 linhas é gerado, como mostrado 
abaixo. 


sdf = spark.range(0, 8 * 1000) .withColumn ( 

Tid', (col('id') % 8).cast('integer') # 1000 rows x 8 groups (if group 
by tad!) 
) .withColumn('v', rand() ) 


Depois, vamos agrupar pela coluna id, o que resulta em 8 grupos com 1.000 linhas 
por grupo. 


O Pandas UDF plus_one é entao criado e aplicado conforme mostrado abaixo: 


import pandas as pd 


def plus_one(pdf: pd.DataFrame) -> pd.DataFrame: 
return pdf.apply(lambda x: x + 1, axis=1) 


res = sdf.groupby("id") .applyInPandas (plus one, schema=sdf.schema) 
res.collect() 


Observe que plus_one pega um DataFrame do Pandas e retorna outro 
DataFrame do Pandas. Para cada grupo, todas as colunas sao passadas juntas 
como um DataFrame do Pandas para 0 plus_one UDF, e os DataFrames do 
Pandas retornados sao combinados em um DataFrame do PySpark. 
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Executar o exemplo acima e sc. show_profiles() imprime o seguinte perfil. 
O perfil abaixo também pode ser inserido no disco por sc.dump_profiles(path). 


2898168 function calls (2881848 primitive calls) in 2.254 seconds 
Ordered by: internal time, cumulative time 
ncalls tottime percall cumtime percall filename: lineno( function) 
~ gee 8.084 8.880 1.384 8.000 series.py:5516(_arith_method) 


8 8.2000 @.800 2.254 @.282 <command-14168941>:1(plus_one) 


O UDF id no perfil (271, destacado acima) corresponde ao do plano Spark para 
res. O plano Spark pode ser mostrado chamando res.explain(). 


== Physical Plan == 


FlatMapGroupsInPandas [id#238], plus_one(id#238, v#240)#271, [id#272, v#273] 
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A primeira linha do corpo do perfil indica o numero total de chamadas monitoradas. 


O cabegalho da coluna inclui 


* ncalls, para o numero de chamadas. 


* tottime, para o tempo total gasto na fungdo dada (excluindo 0 tempo 
gasto em chamadas para subfungées) 


* percall, o quociente de tottime dividido por ncalls 


* cumtime, o tempo cumulativo gasto nesta e em todas as subfungées (da 
invocagao até a saida) 


* percall, o quociente de cumtime dividido por chamadas primitivas 


° filename: lineno( function), que fornece as respectivas informacées 
para cada fungao 


Analisando os detalhes da coluna: plus_ one € acionado uma vez por grupo, 

8 vezes no total; arith method da série Pandas € chamado uma vez por 
linha, 8.000 vezes no total. pandas. DataFrame.apply aplica a fun¢ao lambda 
x: X + 1 linha por linha, sofrendo assim uma alta sobrecarga de invocagao. 


Podemos reduzir essa sobrecarga substituindo pandas. DataFrame.apply por 
pdf + 1, que é vetorizado no Pandas. O Pandas UDF otimizado fica assim: 


import pandas as pd 


def plus_one_optimized(pdf: pd.DataFrame) -> pd.DataFrame: 
return pdf + 1 


res = sdf.groupby("id") .applyInPandas (plus one optimized, schema=sdf. 


schema) 
res.collect() 
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O perfil atualizado 6 mostrado abaixo. 


2384 function calls (2328 primitive calls) in 8.603 seconds 
Ordered by: internal time, cumulative tise 
ncalls tottime percall cumtime percall filename: lineno(function) 

8 8.8008 8.080 8.083 ®.080 frame.py:6857(_arith_method) 


8 8,808 8,088 8.083 8.086 <command-14168952>:1(plus_one_optimized) 


Podemos resumir as otimizagées da seguinte forma: 


¢ Operagao aritmética de 8.000 chamadas para 8 chamadas 
¢ Total de chamadas de fungao de 2.898.160 para 2.384 chamadas 
¢ Tempo total de execugao de 2,300 segundos para 0,004 segundos 


O breve exemplo acima demonstra como o criador de perfil UDF nos ajuda a 
compreender profundamente a execugao, identificar o gargalo de desempenho 
e melhorar o desempenho geral da fungao definida pelo usuario. 


O criador de perfil UDF foi implementado com base no criador de perfil do lado do 
executor, que é projetado para API PySpark RDD. O criador de perfil do lado 
do executor esta disponivel em todas as vers6es ativas do Databricks Runtime. 
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Tanto o criador de perfil UDF quanto o criador de perfil do lado do executor sao 
executados nos workers Python. Eles sao controlados pela configuragao 
spark.python.profile do Spark, que é false por padrao. Podemos habilitar 
essa configuragao do Spark em clusters do Databricks Runtime, conforme 
mostrado abaixo. 


Instances Spark Tags Logging Init Scripts JDBC/ODBC Permissions SSH 


.?) 


spark.python.profile true 


1?) 


No environment variables 
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Conclusao 


Os criadores de perfil PySpark sao implementados com base em cProfile; 
portanto, o relatério do perfil depende da classe Stats. Os acumuladores Spark 
também desempenham um papel importante ao coletar relatérios de perfil dos 
workers Python. 


Criadores de perfil poderosos sao fornecidos pelo PySpark para identificar 
hot loops e sugerir possiveis melhorias. Sao faceis de usar e essenciais para 
melhorar o desempenho dos programas PySpark. O criador de perfil UDF, que 
esta disponivel a partir do Databricks Runtime 11.0 (Spark 3.3), supera todos os 
desafios técnicos e traz insights para fungdes definidas pelo usuario. 


Além disso, ha um esforgo continuo na comunidade de cddigo aberto 
Apache Spark™ para introduzir perfis de meméria em executores. Consulte 
SPARK-40281 para obter mais informagées. 


Comece a experimentar com estes 
notebooks gratuitos da Databricks. 
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Pipelines de dados de streaming de baixa laténcia com Delta Live Tables 


e Apache Kafka 


de FRANK MUNZ 
9 de agosto de 2022 


Delta Live Tables (DLT) é 0 primeiro framework ETL que usa uma abordagem 
declarativa simples para criar pipeline de dados confiavel e gerencia totalmente 
a infraestrutura subjacente em escala para batch e streaming de dados. Muitos 
casos de uso exigem insights acionaveis derivados de dados quase em tempo 
real. O Delta Live Tables permite streaming de dados de pipeline de baixa 
laténcia para oferecer suporte a esses casos de uso com baixas laténcias, 
ingerindo dados diretamente de barramentos de eventos como Apache Kafka, 
AWS Kinesis, Confluent Cloud, Amazon MSK ou Azure Event Hubs. 


Este artigo explicara como usar DLT com Apache Kafka e fornecera o 

cédigo Python necessario para ingerir a streams. A arquitetura de sistema 
recomendada sera explicada e as configuragées DLT relacionadas que valem a 
pena considerar serao exploradas ao longo do caminho. 


Plataformas de streaming 


Barramentos de eventos ou barramentos de mensagens separam os produtores 
de mensagens dos consumidores. Um caso de uso de streaming popular é a 
coleta de dados de cliques de usuarios que navegam em um site em que cada 
interagao do usuario € armazenada como um evento no Apache Kafka. O stream 


&Y databricks 


de eventos do Kafka € entao usado para analise de dados de streaming em tempo 
real. Varios consumidores de mensagens podem ler os mesmos dados do Kafka e 
usar os dados para aprender sobre os interesses do publico, taxas de conversao 
e€ motivos de rejeigao. Os dados de eventos de streaming em tempo real das 
interagdes do usuario muitas vezes também precisam ser correlacionados com 
compras reais armazenadas em um banco de dados de cobranga. 


Apache Kafka 


O Apache Kafka é um barramento popular de eventos de cédigo aberto. O Kafka usa 
o conceito de um tdpico, um log distribuido de eventos somente para aplicativos 
onde as mensagens sao armazenadas em buffer por um determinado periodo 
de tempo. Embora as mensagens no Kafka nao sejam excluidas apés serem 
consumidas, elas também nao sao armazenadas indefinidamente. A retengao de 
mensagens para o Kafka pode ser configurada por t6pico e 0 padrao é de sete dias. 
As mensagens expiradas serao excluidas eventualmente. 


Este artigo € centrado no Apache Kafka. No entanto, os conceitos discutidos 
também se aplicam a muitos outros barramentos de eventos ou sistemas 
de mensagens. 
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Pipelines de dados de streaming 


Em um pipeline de fluxo de dados, o Delta Live Tables e suas dependéncias 
podem ser declaradas com um comando SQL Create Table As Select (CTAS) 
padrao e a palavra-chave DLT “live”. 


Ao desenvolver DLT com Python, o decorador @dlt.table 6 usado para criar 
uma Delta Live Table. Para garantir a qualidade dos dados em um pipeline, o DLT 
usa Expectations, que sao simples clausulas de restrigao SQL que definem o 
comportamento do pipeline com registros invalidos. 


Como as cargas de trabalho de transmissao geralmente vém com volumes 

de dados imprevisiveis, o Databricks emprega dimensionamento automatico 
aprimorado para pipelines de fluxo de dados para minimizar a laténcia geral de 
ponta a ponta e, ao mesmo tempo, reduzir custos ao desligar infraestruturas 
desnecessarias. 


As Delta Live Tables sao totalmente recalculadas, na ordem correta, exatamente 
uma vez para cada execugao do pipeline. 


Por outro lado, as Delta Live Tables de streaming sao estaveis, incrementalmente 
computadas e processam apenas dados que foram adicionados desde a Ultima 
execugao do pipeline. Se a query que define alteragées nas tabelas de streaming 
ao vivo muda, novos dados serao processados com base na nova query, mas os 
dados existentes nao sao recomputados. As Live Tables de streaming sempre 
usam uma fonte de streaming e s6 funcionam em streams somente de aplicativos, 
como Kafka, Kinesis ou Auto Loader. As DLTs de streaming sao baseadas na parte 
superior do Structured Streaming do Spark. 
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Vocé pode encadear varios pipelines de streaming, por exemplo, cargas de 
trabalho com volume de dados muito grande e requisitos de baixa laténcia. 


Ingestao direta de engines de streaming 


Delta Live Tables escritas em Python podem ingerir dados diretamente de um 
barramento de eventos como o Kafka usando Structured Streaming do Spark. 
Vocé pode definir um curto periodo de retengao para o tépico Kafka para 
evitar problemas de conformidade, reduzir custos e entao se beneficiar do 
armazenamento barato, elastico e governavel que o Delta oferece. 


Como primeiro passo no pipeline, recomendamos a ingestao dos dados como 
estao em uma tabela Bronze (bruto) e evitar transformagées complexas que 
possam descartar dados importantes. Como qualquer tabela Delta, a tabela 
Bronze mantera o histérico e permitira que ele execute o GDPR e outras tarefas 
de conformidade. 


bronze 


CREATE STREAMING 
LIVE TABLE AS ... 


@d1t.table() 
def bronze(): 
spark.readStream() ... 


$8 kafka 


downstream computation can be 
full-refreshed without losing data 


short retention table_properties= infinite 
periad {"pipelines.reset.allowed":"false"} retention 


Ingerir dados de streaming do Apache Kafka 
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Ao escrever pipelines DLT em Python, vocé usa a anotagao @dlt.table para 
criar uma tabela DLT. Nao existe nenhum atributo especial para marcar DLTs de 


streaming em Python. Basta usar spark. readStream() para acessar o stream. 


O cédigo de exemplo para criar uma tabela DLT comonome kafka_bronze 
que esta consumindo dados de um tdpico Kafka é 0 seguinte: 


import dlt 
from pyspark.sql.functions import * 
from pyspark.sql.types import * 


TOPIC = "tracker-events" 
KAFKA BROKER = spark.conf.get("KAFKA SERVER" ) 
# subscribe to TOPIC at KAFKA BROKER 
raw_kafka_events = (spark.readStream 
-format("kafka" ) 
-option("subscribe", TOPIC) 
-option("kafka.bootstrap.servers", KAFKA_ BROKER) 
-option("startingOffsets", "earliest") 
-load() 
) 


@dlt.table(table_properties={"pipelines.reset.allowed":"false"}) 
def kafka_bronze(): 
return raw_kafka_events 


pipelines.reset.allowed 


Observe que os barramentos de eventos normalmente expiram mensagens 
apds um determinado periodo de tempo, enquanto o Delta é projetado para 
retengao infinita. 


Isso pode fazer com que os dados de origem no Kafka ja tenham sido excluidos 
ao executar um refresh completo para um pipeline DLT. Nesse caso, nem todos 
os dados histéricos poderiam ser preenchidos com a plataforma de mensagens, 
e os dados estariam faltando nas tabelas DLT. Para evitar a perda do uso de 
dados, use a seguinte propriedade da tabela DLT: 
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pipelines.reset.allowed=false 


Configurar pipelines.reset.allowed como falso evita refreshes para a tabela, mas 
nao impede que gravagoes incrementais para as tabelas ou novos dados fluam 
para a tabela. 


Checkpointing 


Se vocé é desenvolvedor experiente do Structured Streaming do Spark, notara a 
auséncia de checkpointing no cédigo acima. No Structured Streaming do Spark, 

o checkpointing € necess4rio para persistir informagdes de progresso sobre quais 
dados foram processados com sucesso e, em caso de falha, esses metadados 
sa0O usados para reiniciar uma query com falha exatamente de onde parou. 


Considerando que os checkpoints sao necess€rios para a recuperagao de falhas 
com garantias exatamente uma vez no Structured Streaming do Spark, o DLT 

lida com o estado automaticamente, sem qualquer configuragao manual ou 
necessidade de checkpoint explicito. 


Misturando SQL e Python para um pipeline de DLT 


Um pipeline DLT pode consistir em varios notebooks, mas um notebook DLT deve 
ser escrito inteiramente em SQL ou Python (ao contrario de outros notebooks 
do Databricks em que vocé pode ter células de diferentes linguagens em um 
Unico notebook). 


Agora, se sua preferéncia for SQL, vocé pode programar a ingestao de dados 
do Apache Kafka em um notebook em Python e depois implementar a légica 
de transformagées do seu pipeline de dados em outro notebook em SQL. 
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Mapeamento de esquemas 


Ao ler dados da plataforma de mensagens, o stream dos dados é opaco, e um 
esquema deve ser fornecido. 


O exemplo em Python abaixo mostra a definigaéo do esquema de eventos de um 
rastreador de condicionamento fisico e como a parte do valor da mensagem do 
Kafka 6 mapeada para esse esquema. 


event_schema = StructType([ \ 
StructField("time", TimestampType(),True) , \ 
StructField("version", StringType(),True), \ 
StructField("model", StringType(),True) r \ 
StructField("heart_bpm", IntegerType(),True), \ 
StructField("kcal", IntegerType(),True) \ 
]) 


# temporary table, visible in pipeline but not in data browser, 

# cannot be queried interactively 

@dlt.table(comment="real schema for Kakfa payload", 
temporary=True) 


def kafka_silver(): 
return ( 
# kafka streams are (timestamp,value) 
# value contains the kafka payload 


dlt.read_stream("kafka_bronze" ) 

-select(col( "timestamp" ),from_json(col("value" ) 
-cast("string"), event _schema).alias("event") ) 
-select("timestamp", "event.*") 
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Beneficios 


A leitura de dados de streaming em DLT diretamente de um broker de 
mensagens minimiza a complexidade arquitet6nica e fornece menor laténcia 
ponta a ponta, uma vez que os dados s4o transmitidos diretamente do broker 
de mensagens e nenhum intermediario ou passo esta envolvido. 


Ingestao de streaming com intermediario de 
armazenamento de objetos em nuvem 


Para alguns casos de uso especificos, vocé pode querer descarregar dados 
do Apache Kafka, por exemplo, usando um conector Kafka, e armazenar seus 
dados de streaming em um objeto de nuvem intermediario. Em um workspace 
do Databricks, o armazenamento de objetos especifico do fornecedor de 
nuvens pode entao ser mapeado através do Sistema de Arquivos Databricks 
(DBFS) como uma pasta independente de nuvens. Depois que os dados sao 
descarregados, o Databricks Auto Loader pode ingerir os arquivos. 


Object Store / 
DBFS 
Directory 


Streaming 
Live Table 


Auto Loader 


> Kafka FileSink / > 
3 kafka S3 Connector 


O Auto Loader pode ingerir dados com uma Unica linha de cédigo SQL. A 
sintaxe para ingerir arquivos JSON em uma tabela DLT é mostrada abaixo (esta 
agrupada em duas linhas para facilitar a leitura). 


-- INGEST with Auto Loader 
create or replace streaming live table raw 
as select * FROM cloud _files("dbfs:/data/twitter", "json") 
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Observe que o prdprio Auto Loader é uma fonte de dados de streaming e todos 
os arquivos recém-chegados serao processados exatamente uma vez, dai 

a palavra-chave streaming para a tabela bruta que indica que os dados sao 
ingeridos de forma incremental nessa tabela. 


Como o descarregamento de dados de streaming para um armazenamento 
de objetos em nuvem introduz um passo adicional na arquitetura do sistema, 
também aumentara a laténcia ponta a ponta e criara custos adicionais de 
armazenamento. Lembre-se de que o conector Kafka que grava os dados 

do evento no armazenamento de objetos na nuvem precisa ser gerenciado, 
aumentando a complexidade operacional. 


Portanto, a Databricks recomenda como pratica acessar diretamente os dados 
de barramento de eventos do DLT usando o Structured Streaming do Spark, 
conforme descrito acima. 


Outros barramentos de eventos ou sistemas de mensagens 


Este artigo € centrado no Apache Kafka. No entanto, os conceitos discutidos 
também se aplicam a outros barramentos de eventos ou sistemas de mensagens. 
O DLT é compativel com qualquer fonte de dados que o Databricks Runtime 
suporta diretamente. 


Amazon Kinesis 

No Kinesis, vocé escreve mensagens em um stream serverless totalmente 
gerenciado. Igual ao Kafka, o Kinesis nao armazena mensagens permanentemente. 
A retengao de mensagens padrao no Kinesis € de um dia. 


Ao usar 0 Amazon Kinesis, substitua format(“kafka”) por format(“kinesis”) 

no cdédigo Python para ingestao de streaming acima e adicione configuragées 
especificas do Amazon Kinesis com option(). Para obter mais informagées, 
consulte a segao sobre a integragao do Kinesis na documentagao Structured 
Streaming do Spark. 
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Azure Event Hubs 
Para as configuragdes do Azure Event Hubs, confira a documentagao oficial na 
Microsoft e o artigo Delta Live Tables recipes: Consuming from Azure Event Hubs. 


Resumo 


O DLT é muito mais do que apenas o “T” no ETL. Com ele, vocé pode facilmente 
ingerir de fontes de streaming e batch, limpar e transformar dados na Plataforma 
Databricks Lakehouse em qualquer nuvem com qualidade de dados garantida. 


Os dados do Apache Kafka podem ser ingeridos conectando-se diretamente 
a um broker Kafka a partir de um notebook DLT em Python. A perda de dados 
pode ser evitada para um refresh completo do pipeline, mesmo quando os 
dados de origem na camada de streaming do Kafka expiraram. 


Comece agora 


Se vocé € um cliente do Databricks, basta seguir o guia para comegar. Leia as 
notas de versao para saber mais sobre o que esta incluido nesta versado GA. 
Se vocé ainda nao é um cliente do Databricks, inscreva-se para uma versao de 
avaliagao gratuita e veja nossos precos detalhados do DLT aqui. 


Participe da conversa na Comunidade Databricks, onde colegas obcecados por 
dados estado conversando sobre antincios e atualizagées do Data + Al Summit 2022. 
Aprenda. Faga contatos. 


Por ultimo, mas nao menos importante, aproveite a sessdo Mergulhe na engenharia 
de dados do Summit. Nessa sessao, eu apresento 0 cédigo de outro exemplo de 

dados de streaming com uma transmissao ao vivo do Twitter, Auto Loader, Delta 

Live Tables em SQL e analise de sentimento Hugging Face. 
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Streaming em produgao: praticas recomendadas coletadas 


de ANGELA CHU eTRISTEN WENTLING 
12 de dezembro de 2022 


Langar qualquer pipeline de dados ou aplicativo em um estado de produgao exige 
planejamento, teste, monitoramento e manutengao. Os pipelines de streaming nao 
sao diferentes nesse sentido. Neste artigo, apresentamos algumas das consideragdes 
mais importantes para a implantagao de pipelines e aplicagdes de streaming em 
um ambiente de produgao. 


Na Databricks, oferecemos duas maneiras diferentes de criar e executar pipelines 
e aplicagées de streaming: Delta Live Tables (DLT) e Databricks Workflows. O DLT é 
nosso principal produto ETL totalmente gerenciado compativel com pipelines em 
batch e streaming. Oferece desenvolvimento declarativo, operagées automatizadas, 
qualidade de dados, recursos avangados de observabilidade e muito mais. O 
Workflows permite que os clientes executem cargas de trabalho Apache Spark™ 
no ambiente de runtime otimizado do Databricks (ou seja, Photon) com acesso a 
governanga unificada (Unity Catalog) e armazenamento (Delta Lake). Em relagao 
as Cargas de trabalho de streaming, tanto o DLT quanto o Workflows compartilham 
oO mesmo mecanismo central de streaming: Structured Streaming do Spark. No 
caso do DLT, os clientes programam contra a API DLT e o DLT usa 0 mecanismo 

de Structured Streaming nos bastidores. No caso de Jobs, os clientes programam 
diretamente na API Spark. 
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As recomendacoes neste post sao escritas a partir da perspectiva do mecanismo 
de Structured Streaming, a maioria dos quais se aplica tanto a DLT quanto a 
Workflows (embora 0 DLT cuide de alguns desses automaticamente, como Triggers e 
Checkpoints). Agrupamos as recomendacgées sob os titulos “Antes da implantagao” 
e “Depois da implantagao” para destacar quando esses conceitos precisarao ser 
aplicados, e estamos langando esta série de posts com essa divisao entre os dois. 
Também havera contetido adicional aprofundado para algumas das segdes seguintes. 
Recomendamos a leitura de todas as segées antes de iniciar o trabalho para produzir 
um pipeline ou aplicagao de streaming e revisitar essas recomendagoes a medida 
que vocé 0 promove do desenvolvimento ao controle de qualidade e, eventualmente, 
a produgao. 


Antes da implantagao 


Ha muitas coisas que vocé precisa considerar ao criar seu aplicativo de streaming 
para melhorar a experiéncia de produgao. Alguns desses tdpicos, como teste 

de unidade, checkpoints, triggers e gerenciamento de estado, determinarao 

o desempenho do seu aplicativo de streaming. Outros, como convengées de 
nomenclatura e quantos streams executar em quais clusters, tem mais a ver 

com o gerenciamento de varios aplicativos de streaming no mesmo ambiente. 
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Teste unitario 


O custo associado 4a localizagao e corregaéo de um bug aumenta exponencialmente 
quanto mais longe vocé chega no processo de SDLC, e um aplicativo de Structured 
Streaming nao é diferente. Quando vocé esta transformando esse protdtipo em um 
pipeline de produgao reforgado, vocé precisa de um processo de Cl/CD com testes 
integrados. Entaéo, como vocé cria esses testes? 


No inicio, vocé pode pensar que o teste de unidade de um pipeline de streaming 
requer algo especial, mas esse nao € o caso. A orientagao geral para pipelines 
de streaming nao é diferente da orientagao que vocé pode ter ouvido falar 
sobre jobs em batch do Spark. Comega organizando seu cédigo para que ele 
possa ser testado de forma eficaz: 


* Divida seu cédigo em partes testaveis. 


¢ Organize sua légica de negécios em fungdes que chamam outras 
fungodes. Se vocé tem muita logica em um foreachBatch ou implementou 
mapGroupsWithState ou flatMapGroupsWithState, organize esse cddigo 
em varias fungdes que podem ser testadas individualmente. 


e Nao programe em dependéncias do estado global ou de sistemas externos. 


¢ Qualquer fungao que manipule um DataFrame ou conjunto de dados deve 
ser organizada para assumir o DataFrame/conjunto de dados/configuragao 
como entrada e saida do DataFrame/conjunto de dados. 


Depois que seu cédigo é separado de maneira légica, vocé pode implementar 
testes de unidade para cada uma de suas fungoes. As fungées independentes 
do Spark podem ser testadas como qualquer outra fungao nessa linguagem. 
Para testar UDFs e fungdes com DataFrames e conjuntos de dados, ha varios 
frameworks de teste Spark disponiveis. Esses frameworks oferecem suporte 
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a todas as APIs de DataFrame/conjunto de dados para que vocé possa criar 
entradas facilmente, e elas tém assercées especializadas que permitem 
comparar o conteUdo e os esquemas do DataFrame. Alguns exemplos sao: 


¢ O conjunto de testes Spark integrado, concebido para testar todas as 
partes do Spark 


* spark-testing-base, que € compativel com Scala e Python 
* spark-fast-tests, para testar Scala Spark 2 e 3 


¢ chispa, uma versao Python de spark-fast-tests 


Exemplos de cédigo para cada uma dessas bibliotecas podem ser encontrados aqui. 


Mas espere! Estou testando um aplicativo de streaming aqui. Nao preciso fazer 
DataFrames de streaming para meus testes de unidade? A resposta é nao. 
Embora um DataFrame de streaming represente um conjunto de dados sem 

fim definido, quando fungées sao executadas nele, elas sao executadas em um 
microbatch, um conjunto discreto de dados. Vocé pode usar os mesmos testes 
de unidade que usaria para um aplicativo em batch, para streams sem estado e 
com estado. Uma das vantagens do Structured Streaming em relagao a outros 
frameworks € a capacidade de usar 0 mesmo cédigo de transformagao para 
streaming e com outras operagdes em batch para o mesmo destino, ou “sink”. 
Isso permite que vocé simplifique algumas operagées, como backfilling de 
dados, por exemplo, em vez de tentar sincronizar a l6gica entre duas aplicagées 
diferentes, vocé pode simplesmente modificar as fontes de entrada e escrever 
no mesmo destino. Se o sink for uma tabela Delta, vocé podera até mesmo fazer 
essas operacées simultaneamente se ambos os processos forem operagdes 
somente de acréscimo. 
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Triggers 


Agora que vocé sabe que seu codigo funciona, precisa determinar com que 
frequéncia seu stream vai procurar novos dados. E aqui que os triggers entram. 
Definir um trigger € uma das opgdes para 0 comando writeStream, e tema 
seguinte aparéncia: 


// Scala/Java 
. trigger (Trigger.ProcessingTime("30 seconds") ) 


# Python 
. trigger (processingTime='30 seconds’ ) 


No exemplo acima, se um microbatch for concluido em menos de 30 segundos, 
oO mecanismo aguardara o restante do tempo antes de iniciar 0 pr6éximo 
microbatch. Se um microbatch demorar mais de 30 segundos para ser 
concluido, o mecanismo iniciara 0 pr6ximo microbatch imediatamente apds 

o término do anterior. 


Os dois fatores que vocé deve considerar ao configurar seu intervalo de trigger 
sao quanto tempo vocé espera que seu stream processe um microbatch e 

com que frequéncia vocé quer que o sistema verifique novos dados. Vocé pode 
reduzir a laténcia de processamento geral usando um intervalo de trigger menor 
e aumentando os recursos disponiveis para a query de streaming adicionando 
mais workers ou usando instancias otimizadas de compute ou memoria 
adaptadas ao desempenho da sua aplicagao. Esses recursos maiores vem com 
custos maiores, portanto, se seu objetivo 6 minimizar os custos, um intervalo de 
trigger mais longo com menos compute pode funcionar. Normalmente, vocé nao 
definiria um intervalo de trigger maior do que o que normalmente levaria para 
seu stream processar um microbatch para maximizar o uso dos recursos, mas 
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definir um intervalo maior faria sentido se seu stream estiver sendo executado 
em um cluster compartilhado e vocé nao quiser que ele use constantemente os 
recursos do cluster. 


Se nao for necessario que o stream seja executado continuamente, seja porque 
os dados nao chegam com frequéncia ou porque o SLA é de 10 minutos ou 
mais, vocé podera usar a opgao Trigger.Once. Ela iniciara o start, verificara se 

ha algo novo desde a ultima vez que foi executado, processara tudo em um 
batch grande e, em seguida, encerrara. Assim como em um stream em execugao 
continua ao usar o Trigger.Once, 0 checkpoint que garante a tolerancia a falhas 
(veja abaixo) garantira o processamento exatamente uma vez. 


O Spark tem uma nova versao do Trigger.Once chamada Trigger.AvailableNow. 
Enquanto o Trigger.Once processara tudo em um grande batch, 0 que, dependendo 
do tamanho dos dados, pode nao ser o ideal, o Trigger.AvailableNow dividira os 
dados com base nas configuragé6es maxFilesPerTrigger e maxBytesPerTrigger. Isso 
permite que os dados sejam processados em varios batches. Essas configuragdes 
sao ignoradas com Trigger.Once. Vocé pode ver exemplos de configuragao de 
triggers aqui. 


Teste rapido: como transformar seu processo de streaming em um processo 
em batch que mantém automaticamente o controle de onde parou com apenas 
uma linha de cédigo? 


Resposta: altere seu trigger de tempo de processamento para Trigger.Once/ 
Trigger.AvailableNow. Exatamente 0 mesmo cédigo, executado em uma 
programagao, que nao perdera nem reprocessara nenhum registro. 
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Dé um nome ao seu stream 


Vocé nomeia seus filhos, seus pets, agora € hora de nomear seus streams. Ha 
uma opgao do writeStream chamada .queryName que permite dar um nome 
legal ao seu stream. Por qué? Bem, suponha que vocé nao dé nenhum nome. 
Nesse caso, vocé s6 vai precisar ir até a tab Structured Streaming na interface 
do usuario Spark e usar a string <no name> e a GUID incompreensivel que é 
gerada automaticamente como identificador exclusivo do stream. Se vocé tem 
mais de um stream em execugaéo em um cluster e todos eles tém <no name> e 
strings ininteligiveis como identificadores, como vocé encontra cada um deles? 
Se vocé exportar as métricas, como saber qual é qual? 


Facilite as coisas para vocé e dé nomes aos seus streams. Quando estiver 
gerenciando-os na produgao, ficara feliz por ter nomeado e, enquanto isso, 
nomeie suas queries em batch em qualquer cédigo foreachBatch() que tiver. 


Tolerancia a falhas 


Como seu stream se recupera do desligamento? Existem alguns casos 
diferentes em que isso pode entrar em jogo, como falhas no né de cluster 

ou paralisagées intencionais, mas a solugao € configurar o checkpointing. Os 
checkpoints com logs de gravagao antecipada fornecem um grau de protecao 
contra a interrup¢gao do aplicativo de streaming, garantindo que ele possa 
retomar de onde parou pela ultima vez. 


Os checkpoints armazenam os deslocamentos atuais e os valores de 
estado (por exemplo, valores agregados) para seu stream. Os checkpoints 
sao especificos do stream. Portanto, cada um deve ser definido em seu 
proprio local. Isso permitira que vocé se recupere com mais facilidade 

de desligamentos, falhas no cédigo do aplicativo ou falhas ou limitagdes 
inesperadas do provedor de nuvem. 
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Para configurar checkpoints, adicione a opgao checkpointLocation a sua definigao 
de stream: 


// Scala/Java/Python 
streamingDataFrame.writeStream 
-format("delta") 
-option("path", "") 
-queryName("TestStream" ) 
-option("checkpointLocation", "") 
-start() 


Para simplificar, sempre que vocé chamar .writeStream, deve especificar a 
opgao de checkpoint com um local de checkpoint Unico. Mesmo que vocé 
esteja usando foreachBatch e o writeStream em si nao especifique uma opgao 
de caminho ou tabela, vocé ainda deve especificar esse checkpoint. E assim 
que o Structured Streaming do Spark proporciona tolerancia a falhas sem 
complicagées. 


Os esforcgos para gerenciar os checkpoints em seu stream devem ser de pouca 
preocupagaéo em geral. Como disse Tathagata Das: “A maneira mais simples de 
realizar o streaming analitico € nao ter que raciocinar sobre o streaming.” Dito 
isso, uma configuragaéo merece mengao, pois ocasionalmente surgem duvidas 
sobre a manutengao de arquivos de checkpoint. Embora seja uma configuragao 
interna que nao requer configuragao direta, a configuragado spark.sql.streaming. 
minBatchesToRetain (default 100) controla o nimero de arquivos de checkpoint 
que sao criados. Basicamente, 0 numero de arquivos sera aproximadamente 
esse numero vezes dois, pois ha um arquivo criado anotando os deslocamentos 
no inicio dos batches (offsets, também conhecidos como write ahead logs) e 
outro na concluséo dos batches (commits). O ndmero de arquivos é verificado 
periodicamente para limpeza como parte dos processos internos. Isso simplifica 
pelo menos um aspecto da manutengao do aplicativo de streaming de longo 
prazo para vocé. 
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Também é importante observar que algumas alteragdes no cédigo do seu 
aplicativo podem invalidar o checkpoint. E recomendavel verificar qualquer 
uma dessas alteragdes durante as revis6es de codigo antes da implantagao. 
Vocé pode encontrar exemplos de mudangas em que isso pode acontecer 
em Recovery Semantics after Changes in a Streaming Query. Vamos supor 
que vocé queira analisar o checkpoint com mais detalhes ou considerar se o 


checkpoint assincrono pode melhorar a laténcia em seu aplicativo de streaming. 


Nesse caso, eles sao abordados com maior profundidade no artigo Speed Up 
Streaming Queries With Asynchronous State Checkpointing. 


Gerenciamento de estado e RocksDB 


Aplicagées de streaming com estado sao aquelas em que Os registros atuais 
podem depender de eventos anteriores, entao o Spark precisa reter dados 
entre os microbatches. Os dados retidos sao chamados de estado, e o 

Spark os armazenara em um armazenamento de estado e os lera, atualizara 

e excluira durante cada microbatch. As operagoes tipicas com estado sao 
agregacoes de streaming, streaming de dropDuplicates, joins stream-stream, 
mapGroupsWithState ou flatMapGroupsWithState. Alguns tipos comuns de 
exemplos em que vocé precisara pensar sobre o estado da sua aplicagao 
podem ser a sessao ou a agregacao por hora usando métodos de agrupamento 
para calcular métricas de negdécios. Cada registro no armazenamento de estado 
é identificado por uma chave que € usada como parte do calculo de estado, 

e as Chaves mais exclusivas que sao exigidas quanto maior a quantidade de 
dados de estado que serao armazenados. 


Quando a quantidade de dados de estado necessarios para habilitar essas 
operagé6es com monitoragao de estado se torna grande e complexa, isso pode 
degradar o desempenho de suas cargas de trabalho, levando a um aumento da 
laténcia ou até mesmo a falhas. Um indicador tipico de que 0 armazenamento 
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de estado é 0 culpado pela laténcia adicional é a grande quantidade de tempo 
gasto em pausas de coleta de lixo (GC) na JVM. Se vocé esta monitorando 

o tempo de processamento do microbatch, isso pode parecer um aumento 
continuo ou um tempo de processamento extremamente variavel entre 

os microbatches. 


A configuragao padrao para um armazenamento de estado, que é suficiente 
para a maioria das cargas de trabalho de streaming gerais, € armazenar os dados 
de estado na memoria JVM dos executores. Um grande numero de chaves 
(normalmente milhées, consulte a segdo Monitoramento e Instrumentagao na 
parte 2 deste artigo) pode adicionar pressao de memoria excessiva na memoria 
da maquina e aumentar a frequéncia de atingir essas pausas de GC enquanto 
tenta liberar recursos. 


No Databricks Runtime (agora também compativel com o Apache Spark 3.2+), 
vocé pode usar 0 RocksDB como um provedor de armazenamento de estado 
alternativo para aliviar essa fonte de pressao de memoria. O RocksDB é um 
armazenamento de chave persistente incorporavel para armazenamento 
rapido. Ele apresenta alto desempenho por meio de um mecanismo de banco 
de dados estruturado por log escrito inteiramente em C++ e otimizado para 
armazenamento rapido e de baixa laténcia. 


Aproveitar 0 RocksDB como provedor de armazenamento de estado ainda usa 
memi6oria de maquina, mas nao ocupa mais espago no JVM e cria um sistema de 
gerenciamento de estado mais eficiente para grandes quantidades de chaves. No 
entanto, isso nao vem de graga, pois introduz uma etapa extra no processamento 
de cada microbatch. Nao se deve esperar que a introdugao do RocksDB reduza 
a laténcia, exceto quando ela estiver relacionada a pressao de memoria do 
armazenamento de dados de estado na JVM. O armazenamento de estado 
apoiado no RocksDB ainda oferece 0 mesmo grau de tolerancia a falhas que o 
armazenamento de estado regular, pois esta incluido no checkpoint de stream. 
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A configuragao do RocksDB, como a configuragao do checkpoint, € minima por 
design e, portanto, vocé sé precisa declara-la em sua configuragao geral do Spark: 


spark.conf.set ( 
"spark.sql.streaming.stateStore.providerClass", 
"com.databricks.sql.streaming.state.RocksDBStateStoreProvider" ) 


Se vocé estiver monitorando seu stream usando a classe streamingQueryListener, 
vocé também notara que as métricas do RocksDB serao incluidas no campo 
stateOperators. Para informagées mais detalhadas sobre isso, consulte a segao 
RocksDB State Store Metrics de “Structured Streaming in Production”. 


Vale a pena notar que um grande numero de chaves pode ter outros impactos 
adversos, aleém de aumentar 0 consumo de meméria, especialmente com 
chaves de estado ilimitadas ou sem expiragao. Com ou sem RocksDB, 0 estado 
do aplicativo também é copiado em checkpoints para tolerancia a falhas. 
Portanto, faz sentido que, se vocé tiver arquivos de estado sendo criados 

para que nao expirem, vocé continuara acumulando arquivos no checkpoint, 
aumentando a quantidade de armazenamento necessaria e, potencialmente, 

o tempo para grava-los ou também para se recuperar de falhas. Para os dados 
na memoria (veja a segao Monitoramento e Instrumentagao na parte 2 deste 
artigo), esta situagao pode levar a erros um tanto vagos de falta de memoria, 

e, para os dados verificados gravados no armazenamento em nuvens vocé pode 
observar um crescimento inesperado e irracional. A menos que vocé tenha uma 
necessidade comercial de reter o estado de streaming para todos os dados 
que foram processados (e isso é raro), leia a documentagéo de Structured 
Streaming do Spark e implemente suas operagdes com estado para que o 
sistema possa descartar registros de estado que nao sao mais necessarios 
(preste muita atengdo em dropDuplicates e joins stream-stream). 
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Executando varios streams em um cluster 


Assim que seus streams forem totalmente testados e configurados, é hora de 
descobrir como organizd-los em produgao. E um padrao comum empilhar varios 
streams no mesmo cluster Spark para maximizar o uso de recursos e economizar 
custos. Isso 6 bom até certo ponto, mas ha limites para a quantidade que pode 
ser adicionada a um cluster antes que 0 desempenho seja afetado. O driver 
precisa gerenciar todos os streams em execugao no cluster, e todos os streams 
competirao pelos mesmos nucleos entre os workers. Vocé precisa entender o 
que seus streams estao fazendo e planejar sua capacidade adequadamente para 
empilhar de forma eficaz. 


Aqui esta 0 que vocé deve levar em consideragao ao planejar empilhar varios 
streams no mesmo cluster: 


e Seu driver deve ser grande o suficiente para gerenciar todos os seus 
streams. O driver esta tendo dificuldade com a alta utilizagaéo da CPU e 
coleta de lixo? Isso significa que ele esta tentando gerenciar todos os seus 
streams. Reduza o numero de streams ou aumente o tamanho do seu driver. 


¢ Considere a quantidade de dados que cada stream esta processando. 
Quanto mais dados vocé ingere e grava em um sink, mais nucleos 
serao necessarios para maximizar o throughput de cada stream. Vocé 
precisara reduzir o numero de streams ou aumentar o numero de workers 
dependendo da quantidade de dados que estado sendo processados. 
Para fontes como Kafka, vocé precisara configurar quantos nucleos estao 
sendo usados para ingerir com a opgao minPartitions se nao tiver nucleos 
suficientes para todas as partig¢oes em todos os seus streams. 
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¢ Considere a complexidade e 0 volume de dados dos seus streams. 
Se todos os fluxos estiverem fazendo manipulagao minima e apenas 
anexando a um sink, entao cada stream precisara de menos recursos 
por microbatch e vocé podera empilhar mais. Se os streams estiverem 
realizando processamento com estado ou operagées com uso intensivo 
de computagao/meméoria, isso exigira mais recursos para um bom 
desempenho e sera melhor empilhar menos streams. 


¢ Considere scheduler pools. Ao empilhar streams, todos eles contestarao 
os mesmos workers e nUcleos, e um stream que precisa de muitos nucleos 
fara com que os outros streams esperem. Os scheduler pools permitem 
que vocé tenha streams diferentes executados em diferentes partes do 
cluster. Isso permitira que os streams sejam executados em paralelo com 
um subconjunto dos recursos disponiveis. 


¢ Considere seu SLA. Se vocé tiver streams de miss@o critica, isole-os como 
pratica recomendada para que streams de menor criticidade nao os afetem. 


No Databricks, normalmente vemos a pilha de clientes entre 10 e 30 streams em 
um cluster, mas isso varia dependendo do caso de uso. Considere os fatores 
acima para que vocé possa ter uma boa experiéncia com desempenho, custo 

e manutencao. 
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Conclusao 


Algumas das ideias que abordamos aqui certamente merecem seu prdprio tempo 
e tratamento especial com uma discussao mais aprofundada, que vocé podera 
aguardar em aprofundamentos posteriores. No entanto, esperamos que essas 
recomendagées sejam Uteis quando vocé inicia sua jornada ou busca aprimorar 
sua experiéncia de streaming de produgaéo. Continue com a préxima publicagao: 
“Streaming em produgao: praticas recomendadas coletadas (parte 2)”. 


Leia o Guia de primeiros passos para Structured Streaming @® 
do Databricks 


Comece a experimentar com estes 
notebooks gratuitos da Databricks. 
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Streaming em produgao: praticas recomendadas coletadas (parte 2) 


de ANGELA CHU eTRISTEN WENTLING 
10 de janeiro de 2023 


Este 6 o segundo artigo da nossa série de posts em duas partes intitulada 
“Streaming em produgao: praticas recomendadas coletadas”. Aqui discutimos 


as consideragées “Apés a implantagao” de um pipeline de Structured Streaming. 


A maioria das sugestées deste artigo é relevante para os jobs de Structured 
Streaming e para o Delta Live Tables (nosso principal produto de ETL totalmente 
gerenciado compativel com pipelines em batch e streaming). 


Apos aimplantagao 


Apés a implantagao do seu aplicativo de streaming, normalmente ha trés coisas 
principais que vocé precisa saber: 


* Como meu aplicativo esta sendo executado? 
e Os recursos estado sendo usados de forma eficiente? 


* Como gerencio os problemas que surgirem? 


Vamos comegar com uma introdugao a esses tdpicos, seguida de um mergulho 
mais profundo nesta série. 
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Monitoramento e instrumentagao (Como meu aplicativo esta 
sendo executado?) 


As cargas de trabalho de streaming devem ser praticamente automaticas 
depois de implantadas na produgao. No entanto, uma coisa que as vezes pode 
vir a mente é: “como meu aplicativo esta sendo executado?”. Monitorar os 
aplicativos pode assumir diferentes niveis e formas, dependendo do seguinte: 


¢ As métricas coletadas para seu aplicativo (duragao/laténcia do batch, 
throughput...) 


¢ De onde vocé deseja monitorar o aplicativo 


No nivel mais simples, ha um dashboard de streaming (A Look at the New 
Structured Streaming Ul) e um registro integrado diretamente na interface do 
Spark que pode ser usado em diversas situagées. 


Isso se soma a configuragao de alertas de falha em jobs que executam cargas 
de trabalho de streaming. 


Se vocé quiser métricas mais refinadas ou criar agdes personalizadas com base nessas 
métricas como parte da sua base de cédigo, entao StreamingQueryListener 
esta mais alinhado com o que vocé esta procurando. 
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Se vocé quiser que as métricas do Spark sejam relatadas (incluindo rastreamentos Outro ponto a considerar é onde vocé deseja exibir essas métricas para 
no nivel da maquina para drivers ou workers), devera usar 0 sink de métricas observabilidade. Ha um dashboard do Ganglia no nivel do cluster, aplicativos 
da plataforma. de parceiros integrados, como o Datadog, para monitorar cargas de trabalho 


de streaming ou ainda mais opgées de cédigo aberto que vocé pode criar 

usando ferramentas como Prometheus e Grafana. Cada um tem vantagens 
Maker yt e desvantagens a serem consideradas em relagao aos requisitos de custo, 
ae desempenho e manutengao. 


— Se vocé tem volumes baixos de cargas de trabalho de streaming onde as 
vais _ interagées na interface do usuario sdo suficientes ou se decidiu investir em 
uma plataforma de monitoramento mais robusta, deve saber como observar 
= suas Cargas de trabalho de streaming de produgao. Outros artigos sobre 
ie a “Monitoramento e alerta” mais adiante nesta série conterao uma discussao mais 
completa. Em particular, veremos diferentes medidas para monitorar aplicativos 
de streaming e, mais tarde, examinaremos mais profundamente algumas das 


ferramentas que vocé pode aproveitar para observabilidade. 


Otimizagao de aplicativos (os recursos estao sendo usados de forma 
eficaz? Pense em “custo”) 


A préxima preocupagaéo que temos apdés a implantagao em produgao é “meu 
aplicativo esta usando recursos de forma eficaz?”. Como desenvolvedores, 
entendemos (ou aprendemos rapidamente) a diferenga entre cddigo funcional e 
cédigo bem escrito. Melhorar a maneira como seu cddigo é executado geralmente 
€ muito satisfatério, mas o que importa na verdade é€ o custo geral de executa-lo. 


aa eo ee —_— 
a es 


UI de Structured Streaming do Apache Spark As consideragées de custo para aplicativos de Structured Streaming serao em 
grande parte semelhantes as de outros aplicativos Spark. Uma diferenga notavel é 
que nao otimizar as cargas de trabalho de produgao pode ser extremamente caro, 
ja que essas cargas de trabalho sao frequentemente aplicativos “sempre ativos” e, 
portanto, gastos desperdigados podem aumentar rapidamente. Como a assisténcia 


&Y databricks 


O livro completo da engenharia de dados — 2° Edi¢gao 


com otimizagao de custos é sempre requisitada, um post separado nesta série 
abordara isso. Os pontos principais em que nos concentraremos serao a eficiéncia 
de uso e dimensionamento. 


Obter o dimensionamento do cluster certo 6 uma das diferengas mais 
significativas entre eficiéncia e desperdicio em aplicativos de streaming. Isso 
pode ser particularmente complicado porque, em alguns casos, é dificil estimar 
as condicées de carga total do aplicativo em produgao antes que ele esteja de 
fato la. Em outros casos, pode ser dificil devido a variagées naturais no volume 
tratadas ao longo do dia, semana ou ano. Ao implantar pela primeira vez, pode 
ser benéfico superdimensionar ligeiramente, incorrendo em despesas extras 
para evitar a indugao de gargalos de desempenho. Use as ferramentas de 
monitoramento que vocé escolheu implantar depois que o cluster estiver em 
execugao por algumas semanas para garantir a utilizagao adequada do cluster. 
Por exemplo, a CPU e os niveis de memoria estao sendo usados em um nivel alto 
durante o pico de carga ou a carga geralmente € pequena e o cluster pode ser 
reduzido? Mantenha 0 monitoramento regular disso e fique atento as mudangas 
no volume de dados ao longo do tempo. Se isso ocorrer, um redimensionamento 
de cluster pode ser necessario para manter a operagao econdmica. 


Como diretriz geral, vocé deve evitar operagdes de embaralhamento excessivas, 
joins ou um threshold de marca d'agua excessivo ou extremo (nao exceda suas 
necessidades), pois cada um pode aumentar o numero de recursos necessarios 
para executar seu aplicativo. Um threshold grande de marca d'agua fara com 
que o Structured Streaming mantenha mais dados no armazenamento de 
estado entre os batches, levando a um aumento nos requisitos de memoria 

em todo o cluster. Além disso, preste atengao ao tipo de VM configurada: 

vocé esta usando memoria otimizada para seu fluxo intenso de meméria? 
Compute otimizado para seu stream computacionalmente intensivo? Caso 
contrario, observe os niveis de uso de cada um e€ considere tentar um tipo de 
maquina que possa ser mais adequado. Familias mais recentes de servidores de 
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provedores de nuvem com CPUs mais ideais geralmente levam a uma execugao 
mais rapida, 0 que significa que vocé pode precisar de menos deles para 
cumprir seu SLA. 


Solugdo de problemas (Como gerencio os problemas que surgirem?) 


: 


A ultima pergunta que nos fazemos apés a implantagao é “como fago para 
gerenciar os problemas que surgirem?”. Assim como ocorre com a otimizagao 
de custos, a solugao de problemas de aplicativos de streaming no Spark 
costuma ser igual a de outros aplicativos, pois a maior parte da mecanica 
permanece a mesma nos bastidores. Para aplicativos de streaming, os 
problemas geralmente se enquadram em duas categorias: cenarios de falha e 
cenarios de laténcia. 


Cenarios de falha 


Os cenarios de falha geralmente se manifestam com o stream parando com um 
erro, os executores falhando ou uma falha de driver fazendo com que todo o 
cluster falhe. Causas comuns para isso sao: 


e Muitos streams em execugao no mesmo cluster, sobrecarregando o driver. 
No Databricks, isso pode ser visto no Ganglia, em que o né do driver 
aparecera como sobrecarregado antes que o cluster falhe. 


¢ Poucos workers em um cluster ou um tamanho de worker com uma 
proporgao muito pequena de nucleo para meméoria, fazendo com que os 
executores falhem com um erro de falta de memoria. Isso também pode ser 
visto no Databricks no Ganglia antes que um executor falhe, ou na interface 
do usuario do Spark na tab Executores. 


e Usar uma coleta para enviar muitos dados ao driver, fazendo com que ele 
falhe com um erro de falta de memé@ria. 
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Cenarios de laténcia 


Para cenarios de laténcia, seu stream nao sera executado tao rapido quanto 
vocé deseja ou espera. Um problema de laténcia pode ser intermitente ou 
constante. Muitos streams ou um cluster muito pequeno também podem ser a 
causa disso. Algumas outras Ccausas Ccomuns sao: 


¢ Distorgao de dados: quando algumas tarefas acabam com muito mais 
dados do que o resto das tarefas. Com dados distorcidos, essas tarefas 
demoram mais para serem executadas do que as outras, geralmente 
vazando para o disco. Seu stream s6 pode ser executado tao rapido quanto 
a tarefa mais lenta. 


e Executar uma query com estado sem definir uma marca d'agua ou definir 
uma muito longa fara com que seu estado cresga muito, diminuindo a 
velocidade do stream ao longo do tempo e potencialmente levando a 
falhas. 


¢ Sink mal otimizado. Por exemplo, executar um merge em uma tabela Delta 
superparticionada como parte do seu stream. 


¢ Laténcia estavel, mas alta (tempo de execugéo em batch). Dependendo 
da causa, adicionar mais workers para aumentar o numero de nucleos 
atualmente disponiveis para tarefas Spark pode ajudar. Aumentar o numero 
de partigdes de entrada e/ou diminuir a carga por nicleo através das 
configuragées de tamanho do batch também pode reduzir a laténcia. 


Assim como solucionar problemas de um job em batch, vocé usara o Ganglia 
para verificar o uso de clusters e 0 Spark UI para encontrar gargalos de 
desempenho. Ha uma tab Structured Streaming especifica no Spark UI criada 
para ajudar a monitorar e solucionar problemas de aplicativos de streaming. 
Nessa tab, cada stream que esta sendo executado sera listado, e vocé vera o 
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nome do seu stream, se 0 nomeou, OU <No Name> se Nao nomeou. Vocé também 
vera um ID de streaming que ficara visivel na tab Jobs do Spark UI para que 
vocé possa saber quais jobs sao para um determinado stream. 


Vocé notara acima que dissemos quais jobs sao para um determinado stream. 
E um equivoco comum pensar que se vocé olhasse para um aplicativo de 
streaming no Spark UI, veria apenas um job na tab Jobs em execugao continua. 
Em vez disso, dependendo do seu cédigo, vocé vera um ou mais jobs iniciados 
e concluidos para cada microbatch. Cada jobs tera o ID do stream na tab 
Structured Streaming e um numero de microbatch na descrigao, para que vocé 
possa dizer quais jobs acompanham qual stream. Vocé pode clicar nesses jobs 
para encontrar os estagios e tarefas de execugao mais longos, verificar os spills 
de disco e pesquisar por ID de job na tab SQL para encontrar as queries mais 
lentas e verificar seus planos de explicagao. 


Configuration Lidraries Event log Spark UI Driver logs Metrics 


Open in new tab 


start at PnysicalHiow,scalai4z/ 06 


345 (fOdebB94-cca6-4144-b93a-954c958/2396) plan_header_siiver id = 8e21be95-2514-47ee-8018-6de06lfb4bda runid = [Odeb894-cca.. 20 


start at PhysicalFlow.scala:-427 06 
344 (8482cc97-60ea4-48f3-bc49-c463577b16a6) 


it_plan_custom_fields_scd2 Id = fhbb2215e-9159-4809-881d-711f7db7c764 runid = 8482... 20 
start at PhysicalFlow.scala:427 06 


343 (b$8da305-e0ad-42e1-8b80-23486ad9018d) it_plan_channel_scd2 id = 670e4798-D67b-47b7-9042-7d585e668a3d runid = 


b56da3505-eead-42e1-8080-234386a09018d batch = 0 - MERGE operation 
start at PhysicalFlow,scala:427 


342 (175ctb49-78a2-44b8-8896-6639546e17a6) it_plan_versions_sed2 id = 095d468d-ca71-420e-aal3-61e91234113a runid = (75cfb49- 
78a2-44b3-8896-6639546e1786 batch = 0 - MERGE operation - MERGE operation - 
scanning files for matches 


start at PhysicalFlow.scala:427 


341 (f0debB94-cca6-41e4-b93a-954095312396) plan_header_siiver id = Be21be95-2514-47ee-28018-6de06tfb4bda runid = fOdebs94- 20 
¢ca6-41e4-b93a-954c95812396 batch = 0 - MERGE operation - MERGE operation - 06 
scanning files for matches 


start at PhysicalFlow.scala:427 


340 (fOdeb894-cca6-41e4-b93a-954c95812396) plan_header_siiver id = Be21be95-2514-47ee-8018-6de06lfb4bda runid = fOdebso4- 20 
cca6-41e4-b93a-954c95812396 batch = 0 - MERGE operation - MERGE operation - 06 


scanning files for matches 


Tab Jobs na UI do Apache Spark 
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Se vocé clicar em seu stream na tab Structured Streaming, vera quanto tempo as 
diferentes operagées de streaming estao levando para cada microbatch, como 
adicionar um batch, planejar queries e dar commit (veja a captura de tela anterior 
da UI de Structured Streaming do Apache Spark). Vocé também pode ver quantas 
linhas estao sendo processadas, bem como o tamanho do seu armazenamento 
de estado para um stream com monitoramento de estado. Isso pode fornecer 
insights sobre onde estado os possiveis problemas de laténcia. 


Vamos nos aprofundar na solugao de problemas mais adiante nesta série de 
artigos, em que examinaremos algumas das causas e solugdes para os cenarios 
de falha e de laténcia, conforme descrito acima. 


Conclusao 


Vocé deve ter notado que muitos dos tdpicos abordados aqui sao muito 
semelhantes a como outros aplicativos Spark de produgao devem ser 
implantados. Se suas cargas de trabalho so principalmente aplicativos de 
streaming ou processos em batch, a maioria dos mesmos principios sera 
aplicada. Nos nos concentramos mais em coisas que se tornam especialmente 
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importantes ao criar aplicativos de streaming, mas, como temos certeza de que 
vocé ja percebeu, os t6picos que discutimos devem ser incluidos na maioria das 
implantagées de produgao. 


Na maioria dos setores do mundo hoje, as informagées sao necessarias mais 
rapido do que nunca, mas isso nao sera um problema para vocé. Com o Structured 
Streaming do Spark, vocé tem tudo pronto para fazer isso acontecer em escala na 
produgao. Fique de olho nas discussées mais detalhadas sobre alguns dos t6picos 
que abordamos neste artigo e, enquanto isso, continue o streaming. 


Leia a documentagao sobre Structured Streaming 
em produgéo do Databricks © 


Comece a experimentar com estes 
notebooks gratuitos da Databricks. 


O livro completo da engenharia de dados — 2° Edi¢gao 


SECAO 2.6 


Criagao de produtos de dados geoespaciais 


de MILOS COLIC 
6 de janeiro de 2023 


Os dados geoespaciais vém impulsionando a inovagaéo ha séculos, por meio 
do uso de mapas, cartografia e, mais recentemente, do conteudo digital. Por 
exemplo, 0 mapa mais antigo foi encontrado gravado em um pedaco de presa 
de mamute e data de aproximadamente 25.000 AEC. Isso torna os dados 
geoespaciais uma das fontes de dados mais antigas usadas pela sociedade 
para tomar decisées. Um exemplo mais recente, rotulado como o nascimento da 
analise espacial, € o de Charles Picquet em 1832, que usou dados geoespaciais 
para analisar surtos de célera em Paris. Algumas décadas depois, John Snow, 
em 1854, seguiu a mesma abordagem para surtos de cdlera em Londres. Esses 
dois individuos usaram dados geoespaciais para resolver um dos problemas 
mais dificeis de sua €poca e, na verdade, salvar inumeras vidas. Avangando 
rapidamente para o século XX, 0 conceito de Sistemas de Informagao 
Geografica (SIG) foi introduzido pela primeira vez em 1967 em Ottawa, no 
Canada, pelo Departamento de Silvicultura e Desenvolvimento Rural. 


Hoje estamos no meio da revolugaéo do setor de computagao em nuvem: 
escala de supercomputagao disponivel para qualquer organizagao, quase 

que infinitamente escalavel tanto para armazenamento quanto compute. 
Conceitos como malha de dados e marketplace de dados estao surgindo na 
comunidade de dados para abordar questdes como federagao de plataformas 
e interoperabilidade. Como podemos adotar esses conceitos para dados 
geoespaciais, analise espacial e SIGs? Adotando o conceito de produtos de 
dados e abordando o design de dados geoespaciais como um produto. 


&Y databricks 


37 


Neste artigo, apresentaremos um ponto de vista sobre como projetar produtos 
de dados geoespaciais dimensionaveis que sejam modernos e robustos. 
Discutiremos como a Plataforma Databricks Lakehouse pode ser usada para 
liberar todo o potencial dos produtos geoespaciais, que sao um dos ativos mais 
valiosos na solugaéo dos problemas mais dificeis de hoje e do futuro. 


O que é um produto de dados? E como criar um? 


A definigao mais ampla e concisa de “produto de dados” foi cunhada por DJ 
Patil (o primeiro cientista-chefe de dados dos EUA) em Data Jujitsu: The Art of 
Turning Data into Product: “um produto que facilita um objetivo final por meio do 
uso de dados”. A complexidade dessa definigdo (como admitido pelo préprio 
Patil) 6 necessaria para encapsular a amplitude de produtos possiveis, incluindo 
dashboards, relatérios, planilhas do Excel e até extratos CSV compartilhados 
por e-mail. Vocé pode notar que os exemplos fornecidos se deterioram 
rapidamente em qualidade, robustez e governanga. 


Quais sao os conceitos que diferenciam um produto de sucesso de um produto 
malsucedido? E a embalagem? O contetido? A qualidade do contetido? Ou é 
apenas a adogao do produto no mercado? A Forbes define os 10 itens essenciais 
para um produto de sucesso. Uma boa estrutura para resumir isso é através da 
piramide de valor. 
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Each use adds value to the user and reduces their 
likelihood of looking for another product 


Scalability 


Explainability 


Figura 1: Piramide de valor do produto (fonte) 


A piramide de valor fornece uma prioridade em cada aspecto do produto. Nem 
todas as perguntas de valor que fazemos sobre 0 produto tém o mesmo peso. 
Se o resultado nao for Util, nennum dos outros aspectos sera importante. O 
resultado nao € realmente um produto, mas se torna mais poluente de dados 
para o grupo de resultados Uteis. Da mesma forma, a escalabilidade s6 importa 
depois que a simplicidade e a explicabilidade sao abordadas. 


Como a piramide de valor esta relacionada aos produtos de dados? Cada saida 
de dados, para ser um produto de dados: 


¢ Deve ter uma utilidade clara. A quantidade de dados que a sociedade esta 
gerando 6 rivalizada apenas pela quantidade de poluentes de dados que 
estamos gerando. Esses sao resultados que nao tém valor e uso claros, 
muito menos uma estratégia sobre o que fazer com eles. 
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* Deve ser explicavel. Com 0 surgimento da IA/ML, a explicabilidade 


se tornou ainda mais importante para a tomada de decisdo baseada 
em dados. Os dados sao tao bons quanto os metadados que os 
descrevem. Pense nisso em termos de alimentos: o sabor importa, mas 
um fator mais importante € o valor nutricional dos ingredientes. 


Deve ser simples. Um exemplo de uso indevido de produto é usar 
um garfo para comer cereais em vez de uma colher. Além disso, a 
simplicidade é essencial, mas nao suficiente: além da simplicidade 
os produtos devem ser intuitivos. Sempre que possivel, tanto 0 uso 
intencional como o nao intencional dos dados devem ser 6Obvios. 


Deve ser escalavel. Os dados sao um dos poucos recursos que cresce 
com 0 uso. Quanto mais dados vocé processa, mais dados tem. Se 

as entradas e saidas do sistema nao forem limitadas e crescerem 
constantemente, o sistema deve ser escalavel em poténcia de 
compute, capacidade de armazenamento e capacidade de compute 
expressiva. Plataformas de dados em nuvem, como Databricks, estao 
em uma posigao Unica para responder a todos os trés aspectos. 


Deve gerar habitos. No dominio dos dados, nao estamos preocupados 
com aretengao de clientes, como é€ 0 caso dos produtos de varejo. No 
entanto, o valor da geragao de habitos é dbvio se aplicado as praticas 
recomendadas. Os sistemas e as saidas de dados devem apresentar 
as praticas recomendadas e promové-las: deve ser mais facil usar os 
dados e o sistema da forma pretendida do que o contrario. 


Os dados geoespaciais (e, na verdade, quaisquer produtos de dados) devem 
aderir a todos os aspectos acima mencionados. Além dessa tarefa dificil, os 
dados geoespaciais tém algumas necessidades especificas. 


38 


O livro completo da engenharia de dados — 2° Edi¢gao 


Padroes de dados geoespaciais 


Os padroes de dados geoespaciais sdo usados para garantir que os dados 
geograficos sejam coletados, organizados e compartilhados de forma 
consistente e confiavel. Estes padrées podem incluir diretrizes para coisas 
como formatagao de dados, sistemas de coordenadas, projegdes de mapas e 
metadados. A adesao aos padrées facilita o compartilhamento de dados entre 
diferentes organizagoes, permitindo maior colaboragao e acesso mais amplo a 
informagées geograficas. 


A Comissao Geoespacial (governo do Reino Unido) definiu o UK Geospatial Data 
Standards Register como um repository central para padrées de dados a serem 
aplicados no caso de dados geoespaciais. Além disso, a missao desse Register é: 


¢ “Garantir que os dados geoespaciais do Reino Unido sejam mais 
consistentes, coerentes e utilizaveis em uma ampla gama de 
sistemas.” — Esses conceitos sao uma chamada para a importancia da 
explicabilidade, utilidade e geragao de habitos (possivelmente outros 
aspectos da piramide de valores). 


¢ “Capacitar a comunidade geoespacial do Reino Unido para que se 
envolva mais com os padrées e orgaos de padrées relevantes.” — A 
geracgao de habitos na comunidade é tao importante quanto o design 
robusto e critico do padrao. Se nao forem adotados, os padr6ées serao 
inuteis. 
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¢ “Defender a compreens&o e 0 uso dos padrées de dados geoespaciais 
em outros setores do governo.” — A piramide de valor também se aplica 
aos padr6es. Conceitos como facilidade de ades4o (ttil/simplicidade), 
finalidade do padrao (explicabilidade/usabilidade), adogdo (geragao de 
habito) sAo fundamentais para a geragaéo de valor de um padrao. 


Uma ferramenta critica para alcangar a missao dos padrées de dados sao os 
principios de dados FAIR: 


¢ Finddveis — O primeiro passo no (re)uso de dados é encontra-los. 
Metadados e dados devem ser faceis de encontrar para humanos e 
computadores. Metadados legiveis em maquina sao essenciais para a 
descoberta automatica de conjuntos de dados e servic¢os. 


¢ Acessiveis — Depois que 0 usuario encontra os dados necessarios, ele 
precisa saber como podem ser acessados, possivelmente incluindo 
autenticagao e autorizagao. 


¢ Interoperaveis — Os dados geralmente precisam ser integrados a outros 
dados. Além disso, os dados precisam interoperar com aplicativos ou fluxos 
de trabalho para analise, armazenamento e processamento. 


¢ Reutilizaveis — O objetivo final dos principios FAIR € otimizar a reutilizagao 
de dados. Para isso, os metadados e os dados devem ser bem descritos para 
que possam ser replicados e/ou combinados em diferentes configuragées. 
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Compartilhamos a crenga de que os principios FAIR sao cruciais para o design 
de produtos de dados escalaveis nos quais podemos confiar. Para ser justo, os 
principios FAIR sao baseados no senso comum, entao por que sao fundamentais 
para nossas consideragées? “O que vejo nos principios FAIR ndo € novo por si 
sd, mas o que eles fazem bem é articular, de forma acessivel, a necessidade 

de uma abordagem abrangente para a melhoria de dados. Essa facilidade de 
comunicagaéo é o motivo pelo qual os principios FAIR estéo sendo usados cada 
vez mais amplamente como um guarda-chuva para a melhoria de dados, e néo 
apenas na comunidade geoespacial.” — Artigo “A FAIR wind sets our course for 
data improvement”. 


Para apoiar ainda mais essa abordagem, o Comité Federal de Dados Geograficos 
desenvolveu o Plano Estratégico de Infraestrutura Nacional de Dados Espaciais 
(NSDI), que abrange os anos de 2021 a 2024 e foi aprovado em novembro de 
2020. Os objetivos do NSDI sao, em esséncia, os principios FAIR e transmitir a 
mesma mensagem de projetar sistemas que promovam a economia circular de 
dados: produtos de dados que fluem entre as organizagdes seguindo padr6ées 
comuns e em cada etapa da cadeia de fornecimento de dados desbloqueiam 
novos valores e novas oportunidades. O fato de que esses principios estao 
permeando diferentes jurisdigdes e sao adotados em diferentes reguladores 

é uma prova da robustez e solidez da abordagem. 


NSDI Strategic Goals 


Figura 2: 


Objetivos estratégicos do NDSI 
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Os conceitos FAIR combinam muito bem com o design do produto de dados. 
Na verdade, os principios FAIR estao atravessando toda a piramide de valor do 
produto e forma um ciclo de valor. Ao adotar os principios de piramide de valor 
e FAIR, projetamos produtos de dados com perspectiva interna e externa. Isso 
promove a reutilizagaéo de dados em vez do acumulo de dados. 


Findable Accessible 


Scalability 
Explainability 


Usefulness 


ff 


Por que os principios FAIR sao importantes para dados geoespaciais e produtos 


Reproducible Interoperable 


de dados geoespaciais? Os principios FAIR sao transcendentes aos dados 
geoespaciais, sao, na verdade, transcendentes aos dados, sao um sistema 
simples, mas coerente, de principios orientadores para um bom design, e esse 
bom design pode ser aplicado a qualquer coisa, incluindo dados geoespaciais 
e sistemas geoespaciais. 
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Sistemas de indexagao de grade 


Nas solugoées SIG tradicionais, o desempenho das operagoes espaciais é 
geralmente alcangado através da construgaéo de estruturas em 4rvore (KD trees, 
ball trees, Quad trees etc.). O problema com as abordagens em 4rvore é que 
elas eventualmente quebram o principio da escalabilidade: quando os dados sao 
grandes demais para serem processados para construir a arvore e a computagao 
necessaria para construir a arvore € muito longa e vai contra o propésito. Isso 
também afeta negativamente a acessibilidade dos dados. Se nao pudermos 
construir a arvore, nao poderemos acessar os dados completos e, na verdade, 
nao poderemos reproduzir os resultados. Neste caso, os sistemas de indexagao 
de grade fornecem uma solugao. 


Os sistemas de indexagao de grade sao criados desde 0 inicio tendo em mente 
os aspectos de escalabilidade dos dados geoespaciais. Em vez de construir as 
arvores, eles definem uma série de grades que cobrem a area de interesse. No 
caso do H3 (desenvolvido pela Uber), a grade cobre a 4rea da Terra. No caso 

de sistemas de indexagao de grade local (por exemplo, British National Grid), 

eles podem cobrir apenas a area especifica de interesse. Essas grades sao 
compostas por células que possuem identificadores exclusivos. Existe uma 
relagao matematica entre a localizagao e a célula na grade. Isso torna os sistemas 
de indexagao de grade muito escalaveis e de natureza paralela. 
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Outro aspecto importante dos sistemas de indexagao de grade é que eles sao 
de cédigo aberto, permitindo que os valores de indexagao sejam universalmente 
aproveitados por produtores de dados e consumidores. Os dados podem 

ser enriquecidos com as informagoées da indexagao de grade em qualquer 

etapa de sua jornada pela cadeia de fornecimento de dados. Isso torna os 
sistemas de indexagao de grade um exemplo de padrées de dados orientados 
pela comunidade. Os padrées de dados orientados pela comunidade por 
natureza nao exigem imposigao, que adere totalmente ao aspecto de geracgao 
de habitos da piramide de valor e aborda significativamente os principios de 
interoperabilidade e acessibilidade da FAIR. 


Figura 5: Exemplo de como usar H3 para expressar padrées de espera de voo 
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A Databricks anunciou recentemente a compatibilidade nativa para o sistema 
de indexagao de grade H3 seguindo a mesma proposta de valor. A adogao 

de padrées comuns do setor, orientados pela comunidade, é a Unica maneira 
de impulsionar adequadamente a geragao de habitos e a interoperabilidade. 
Para fortalecer essa declaragao, organizagdes como CARTO, ESRI e Google 
tém promovido o uso de sistemas de indexagao de grade para projetos de 
SIGs escalaveis. Além disso, 0 projeto Mosaic do Databricks Labs 6 compativel 
com o British National Grid como o sistema de indice de grade padrao que é 
amplamente usado no governo do Reino Unido. Os sistemas de indexagao de 
grade sao fundamentais para a escalabilidade do processamento de dados 
geoespaciais e para projetar adequadamente solugées para problemas 
complexos (por exemplo, Figura 5: Padrées de espera de voo usando H3). 


Diversidade de dados geoespaciais 


Os padroes de dados geoespaciais gastam uma quantidade sélida de esforgos 
em relagaéo a padronizagao do formato dos dados, e 0 formato € uma das 
consideragoes mais importantes quando se trata de interoperabilidade 

e reprodutibilidade. Além disso, se a leitura dos seus dados € complexa, 

como podemos falar em simplicidade? Infelizmente, os formatos de dados 
geoespaciais sAo em geral complexos, pois os dados podem ser produzidos em 
varios formatos, incluindo formatos de cédigo aberto e formatos especificos 
do fornecedor. Considerando apenas dados vetoriais, pbodemos esperar que os 
dados cheguem em WKT, WKB, GeoJSON, web CSV, CSV, Shape File, GeoPackage 
e muitos outros. Por outro lado, se estamos considerando dados rasterizados, 
podemos esperar que os dados cheguem em qualquer numero de formatos, 
como GeoTiff, netCDF, GRIB ou GeoDatabase. Para obter uma lista abrangente 
de formatos, consulte este artigo. 


O livro completo da engenharia de dados — 2° Edi¢gao 


O dominio de dados geoespaciais € tao diversificado e cresceu organicamente 
ao longo dos anos em torno dos casos de uso que estava abordando. A utilizagao 
de um ecossistema tao diversificado € um desafio enorme. Um esforco recente 
do Open Geospatial Consortium (OGC) para padronizar o Apache Parquet e 

sua especificagaéo de esquema geoespacial GeoParquet € um passo na diregao 
certa. A simplicidade é um dos principais aspectos do projeto de um produto 
bom escalavel e robusto — a unificagao leva a simplicidade e aborda uma das 
principais fontes de fricgao no ecossistema — a ingestao de dados. Padronizar 
para GeoParquet traz muito valor que aborda todos os aspectos dos dados de 
FAIR e piramide de valor. 


COMPUTING 
ENGINES & Google amazon Sth 
LIBRARIES BigQuery gB id REDSHIFT ye STOWTIOKE GeoPandas 
databricks 
€dremio a “ae price 
o) presto SPOOL oe 
> it 
SELECT data FROM myTable JOIN providerTable 
CART® FOURSQUARE (pldnet. ea SAFEGRAPH data.parquet 
CLOUD __ PROVIDERS DATA ENTERPRISE DATA 
STORAGE 


Figura 6: GeoParquet como formato de dados padrao geoespacial 
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Por que introduzir outro formato em um ecossistema ja complexo? GeoParquet 
nao é um formato novo, € uma especificagao de esquema para o formato 
Apache Parquet que ja € amplamente adotado e usado pela industria e pela 
comunidade. O Parquet como formato base é compativel com colunas binarias 
e permite o armazenamento de carga de dados arbitraria. Ao mesmo tempo, 

o formato oferece suporte a colunas de dados estruturados que podem 
armazenar metadados junto com a carga de dados. Isso 0 torna uma escolha 
que promove a interoperabilidade e a reprodutibilidade. Por fim, o formato Delta 
Lake foi criado com base no Parquet e traz propriedades ACID para a mesa. As 
propriedades ACID de um formato sao cruciais para a reprodutibilidade e para 
resultados confiaveis. Além disso, o Delta é o formato usado pela solugao de 
compartilhamento de dados escalavel Delta Sharing. 


O Delta Sharing permite o compartilhamento de dados em escala empresarial 
entre qualquer nuvem publica usando Databricks (opgées DIY para nuvem privada 
estado disponiveis usando médulos de cédigo aberto). O Delta Sharing abstrai 
completamente a necessidade de APIs Rest personalizadas para expor dados 

a terceiros. Qualquer ativo de dados armazenado no Delta (usando 0 esquema 
GeoParquet) torna-se automaticamente um produto de dados que pode ser 
exposto a partes externas de forma controlada e controlada. O Delta Sharing foi 
criado do zero com as praticas recomendadas de seguranga em mente. 
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Figura 7: Delta Sharing simplificando 0 acesso aos dados no ecossistema 


Economia de dados circulares 


cépia dos ativos do que reutilizar os existentes? Ou era muito dificil encontrar 


Emprestando os conceitos do dominio de sustentabilidade, podemos 
os ativos de dados existentes ou talvez fosse muito complexo definir padrées 


definir uma economia circular de dados como um sistema no qual os dados 
sao coletados, compartilhados e usados de forma a maximizar seu valor, 
minimizando o desperdicio e os impactos negativos, como tempo de compute 
desnecessario, insights nao confiaveis ou agdes tendenciosas baseadas em 
poluentes de dados. A reutilizagao € o conceito-chave nesta consideragao: 
como podemos minimizar a “reinvengao da roda”? Existem indmeros ativos 


de acesso a dados? 


A duplicagao de ativos de dados tem muitos aspectos negativos nas 
consideragoes FAIR e nas consideragées de piramide de valor de dados — 

ter muitos ativos de dados semelhantes (mas diferentes) que representam 

a mesma area e oS mesmos conceitos pode deteriorar as consideragdes de 
simplicidade do dominio de dados — torna-se dificil identificar o ativo de 
dados em que realmente podemos confiar. Também pode ter implicagées muito 


de dados que representam a mesma 4rea, oS Mesmos conceitos com apenas 
pequenas alteragdes para melhor corresponder a um caso de uso especifico. 
Isso se deve as otimizagdes reais ou ao fato de que foi mais facil criar uma nova 
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negativas na geracgao de habitos. Surgiraéo muitas comunidades de nicho que se 
padronizarao ignorando as praticas recomendadas do ecossistema mais amplo 
ou, pior ainda, nado padronizarao nada. 


Em uma economia circular de dados, os dados sao tratados como um recurso 
valioso que pode ser usado para criar novos produtos e servicgos, além 

de melhorar os ja existentes. Esta abordagem incentiva a reutilizagao ea 
reciclagem de dados, em vez de trata-los como um bem descartavel. Mais uma 
vez, utilizamos a analogia da sustentabilidade no sentido literal: argumentamos 
que esta é a forma correta de abordar o problema. Os poluentes de dados sao 
um verdadeiro desafio para as organizagoes, tanto interna como externamente. 
Um artigo do The Guardian afirma que menos de 1% dos dados coletados sao 
realmente analisados. Ha muita duplicagao de dados, a maioria dos dados é 
dificil de acessar e a obtengao do valor real € complicada demais. A economia 
circular de dados promove as melhores praticas e a reutilizagao dos ativos 

de dados existentes, permitindo uma interpretagao e percepgées mais 
consistentes em todo o ecossistema de dados. 
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A interoperabilidade 6 um componente essencial dos principios de dados FAIR 
e, a partir da interoperabilidade, vem a mente uma questao de circularidade. 
Como podemos projetar um ecossistema que maximize a utilizagao e a 
reutilizagao dos dados? Mais uma vez, os principios FAIR, juntamente com a 
piramide de valor, oferecem respostas. A capacidade de localizagao dos dados 
é fundamental para a reutilizagao de dados e para solucionar a poluigao de 
dados. Com ativos de dados que podem ser descobertos facilmente, podemos 
evitar a recriagao dos mesmos ativos de dados em varios lugares com apenas 
uma pequena alteragao. Em vez disso, obtemos um ecossistema de dados 
coerente com dados que podem ser facilmente combinados e reutilizados. 

A Databricks anunciou recentemente o Databricks Marketplace. A ideia por 
tras do Marketplace esta alinhada com a definigao original de produto de 
dados de DJ Patil. O Marketplace oferecera suporte ao compartilhamento de 
conjuntos de dados, notebooks, dashboards e modelos de machine learning. 

O médulo essencial para esse mercado € 0 conceito de Delta Sharing: 0 canal 
dimensionavel, flexivel e robusto para o compartilhamento de qualquer dado, 
incluindo dados geoespaciais. 
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Projetar produtos de dados escalaveis que permanecerao no mercado é 
crucial. Para maximizar o valor agregado de cada produto de dados, deve-se 
considerar fortemente os principios FAIR e a piramide de valor do produto. 
Sem esses principios orientadores, aumentaremos apenas os problemas que ja 
estao presentes no sistemas atuais. Cada produto de dados deve resolver um 
problema Unico e deve resolvé-lo de forma simples, reprodutivel e robusta. 


Leia mais sobre como a Plataforma Databricks Lakehouse 
pode ajudar vocé a acelerar o retorno sobre o investimento 
dos seus produtos de dados no e-book: Uma nova abordagem 
para o Data Sharing. 


Comece a experimentar com estes 
notebooks gratuitos da Databricks. 
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SECAO 2.7 


Linhagem de dados com o Unity Catalog 


de PAUL ROOME, TAO FENG E SACHIN THAKUR 
8 de junho de 2022 


Este artigo explicara a importancia da linhagem de dados, alguns dos casos 
de uso comuns, nossa visao para uma melhor transparéncia de dados e 
compreensao de dados com linhagem de dados. 


O que é linhagem de dados e por que é importante? 


A linhagem de dados descreve as transformagoes e refinamentos de dados da 
fonte ao insight. A linhagem inclui a captura de todos os metadados e eventos 
relevantes associados aos dados em seu ciclo de vida, incluindo a origem do 
conjunto de dados, quais outros conjuntos de dados foram usados para cria-lo, 
quem o criou e quando, quais transformagoes foram realizadas, quais outros 
conjuntos de dados aproveita-lo e muitos outros eventos e atributos. Com uma 
solugao de linhagem de dados, as equipes de dados obtém uma visao completa 
de como os dados sao transformados e como fluem em seus bens de dados. 


A medida que cada vez mais organizagédes adotam uma cultura orientada por 
dados e configuram processos e ferramentas para democratizar e dimensionar 
dados elA, a linhagem de dados esta se tornando um pilar essencial de uma 
estratégia pragmatica de governanga e gerenciamento de dados. 


Para entender a importancia da linhagem de dados, destacamos abaixo alguns 
dos casos de uso comuns que ouvimos de nossos clientes. 
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Analise de impacto 

Os dados passam por varias atualizagées ou revisdes ao longo de seu ciclo 

de vida, e entender o impacto potencial de qualquer mudanga de dados 

nos consumidores downstream torna-se importante do ponto de vista de 
gerenciamento de riscos. Com a linhagem de dados, as equipes de dados podem 
ver todos os consumidores downstream (aplicativos, dashboards, modelos de 
machine learning ou conjuntos de dados etc.) afetados por alteragdes de dados, 
entender a gravidade do impacto e notificar as partes interessadas relevantes. A 
linhagem também ajuda as equipes de Tl a comunicar proativamente migragdes 
de dados para as equipes apropriadas, garantindo a continuidade dos negocios. 


Entendimento e transparéncia de dados 

As organizagées lidam com um influxo de dados de varias fontes, e construir 
uma melhor compreensao do contexto em torno dos dados é fundamental para 
garantir a confiabilidade dos dados. A linhagem de dados é uma ferramenta 
poderosa que permite que os lideres de dados promovam uma melhor 
transparéncia e compreensao dos dados em suas organizagées. A linhagem de 
dados também capacita os consumidores de dados, como cientistas de dados, 
engenheiros de dados e analistas de dados, a terem conhecimento de contexto a 
medida que realizam analises, resultando em melhores resultados de qualidade. 
Finalmente, os administradores de dados podem ver quais conjuntos de dados 
nao sao mais acessados ou se tornaram obsoletos para se aposentar dos dados 
desnecessarios e garantir a qualidade dos dados para os usuarios finais. 
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Depuragao e diagnostico 

Vocé pode ter todas as verificagées e equilibrios em vigor, mas algo acabara 
falhando. A linhagem de dados ajuda as equipes de dados a realizar uma 
analise de causa raiz de quaisquer erros em seu pipeline de dados, aplicativos, 
dashboards, modelo de machine learning etc., rastreando o erro até sua origem. 
Isto reduz significativamente o tempo de depuragao, economizando dias ou, em 
muitos casos, meses de esforgo manual. 


Prontidao para conformidade e auditoria 

Muitas regulamentagcées de conformidade, como o Regulamento Geral sobre a 
Protegado de Dados (RGPD), a Lei de Privacidade do Consumidor da Califérnia 
(CCPA), a Lei de Portabilidade e Responsabilidade de Seguros de Satide (HIPPA), 
o Comité de Supervisdo Bancaria da Basileia (BCBS) 239 e a Lei Sarbanes-Oxley 
(SOX), exigem que as organizagées tenham um entendimento claro e visibilidade 
do fluxo de dados. Como resultado, a rastreabilidade dos dados se torna um 
requisito fundamental para que a arquitetura de dados atenda as normas legais. A 
linhagem de dados ajuda as organizagoes a estarem em conformidade e prontas 
para a auditoria, aliviando assim a sobrecarga operacional de criar manualmente 
as trilhas de fluxos de dados para fins de relatérios de auditoria. 
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Transparéncia sem esforgo e controle proativo 
com linhagem de dados 


O lakehouse oferece uma arquitetura pragmatica de gerenciamento de dados que 
simplifica substancialmente a infraestrutura de dados empresariais e aceleraa 
inovagao, unificando seus casos de uso de armazenamento de dados e IA em uma 
Unica plataforma. Acreditamos que a linhagem de dados é um facilitador essencial 
para uma melhor transparéncia de dados e compreensao de dados em seu 
lakehouse, superando os relacionamentos entre dados, trabalhos e consumidores, 
e ajudando as organizagoes a adotar praticas proativas de gerenciamento de 
dados. Por exemplo: 


* Como responsavel por um dashboard, vocé quer receber notificagao da 
proxima vez que uma tabela da qual seu dashboard depende no tiver sido 
carregada corretamente? 


* Como profissional de machine learning que desenvolve um modelo, vocé 
quer receber um alerta de que um recurso critico em seu modelo sera 
descontinuado em breve? 


¢ Como administrador de governanga, vocé quer controlar automaticamente 
oO acesso aos dados com base na procedéncia? 


Todos esses recursos dependem da coleta automatica de linhagem de dados 
em todos os casos de uso e personas, e € por isso que a linhagem de dados e 0 
lakehouse sao uma combinagao poderosa. 
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Linhagem de dados para notebooks, workflows, dashboards 


Seguranga integrada: os graficos de linhagem no Unity Catalog reconhecem 
privilégios e compartilham 0 mesmo modelo de permissao que o Unity Catalog. 
Se os usuarios nao tiverem acesso a uma tabela, eles nao poderao explorar a 
linhagem associada a tabela, adicionando uma camada adicional de seguranga 
para consideragoées de privacidade. 


Facilmente exportavel via API REST: A linhagem pode ser visualizada no 
Data Explorer quase em tempo real e recuperada por meio da API REST para dar 
suporte a integragées com nossos parceiros de catalogo. 


Como comegar com linhagem de dados no Unity Catalog 


A linhagem de dados esta disponivel com niveis Databricks Premium e Enterprise 
sem custo adicional. Se vocé ja € um cliente Databricks, siga os guias de linhagem 
de dados (AWS | Azure) para comegar. Se vocé nao é um cliente Databricks, 
inscreva-se para uma avaliacao gratuita com um workspace Premium ou Enterprise. 
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SECAO 2.8 


Ingestao facil para lakehouse com COPY INTO 


de AEMRO AMARE, EMMA LIU, AMIT KARA eJASRAJ DANGE 
17 de janeiro de 2023 


Uma nova arquitetura de gerenciamento de dados, conhecida como data 
lakehouse, surgiu de forma independente em muitas organizagées e casos 

de uso para dar suporte a IA e ao BI diretamente em grandes quantidades de 
dados. Um dos principais fatores de sucesso do uso do data lakehouse para 
fungdes analiticas e machine learning € a capacidade de ingerir dados de varios 
tipos de forma rapida e facil, incluindo dados de plataformas de armazenamento 
no local (data warehouses, mainframes), dados de streaming em tempo real e 
ativos de dados em massa. 


Como a ingestao de dados no lakehouse € um processo continuo que alimenta 
0 proverbial pipeline de ETL, vocé precisara de varias opgoes para ingerir varios 
formatos, tipos e laténcias de dados. Para dados armazenados em objetos 

em nuvens como AWS S83, Google Cloud Storage e Azure Data Lake Storage, o 
Databricks oferece Auto Loader, um recurso nativamente integrado, que permite 
que engenheiros de dados ingiram milhdédes de arquivos do armazenamento 

em nuvens continuamente. Em outros casos de transmissao (por exemplo, 
sensor loT ou dados clickstream), o Databricks fornece conectores nativos para 
Structured Streaming do Apache Spark para ingerir rapidamente dados de filas 
de mensagens populares, como Apache Kafka, Azure Event Hubs ou AWS Kinesis 
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em baixas laténcias. Além disso, muitos clientes podem aproveitar ferramentas de 
ingestao populares que se integram ao Databricks, como o Fivetran, para ingerir 
facilmente dados de aplicativos corporativos, bancos de dados, mainframes 

e muito mais no lakehouse. Por fim, o analista pode usar 0 comando simples 
“COPY INTO” para extrair novos dados automaticamente para o lakehouse, sem a 
necessidade de controlar quais arquivos ja foram processados. 


Este artigo se concentra em COPY INTO, um comando SQL simples, mas poderoso, 
que permite realizar a ingestao de arquivos de batches no Delta Lake a partir 
de armazenamentos de objetos em nuvens. E idempotente, 0 que garante a 
ingestao de arquivos com semantica exatamente uma vez quando executado 
varias vezes, suportando acréscimos incrementais e transformagées simples. 
Pode ser executado uma vez, de forma ad hoc, e pode ser agendado através do 
Databricks Workflows. Nas versées recentes do Databricks Runtime, COPY INTO 
introduziu novas funcionalidades para visualizagao de dados, validagao, tratamento 
aprimorado de erros e uma nova maneira de copiar para uma tabela Delta Lake 
sem esquema para que os usuarios possam come¢ar rapidamente, completando a 
jornada do usuario de ponta a ponta para ingerir de armazenamentos de objetos de 
nuvens. Vamos dar uma olhada nos casos de uso populares de COPY INTO. 
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1. Ingerindo dados pela primeira vez 


COPY INTO requer a existéncia de uma tabela a medida que ingere os dados 
em uma tabela Delta de destino. No entanto, vocé nao tem ideia de como seus 
dados se parecem. Primeiro, vocé cria uma tabela Delta vazia. 


CREATE TABLE my example data; 


Antes de gravar seus dados, convém visualiza-los e garantir que os dados 
paregam corretos. O modo COPY INTO Validate € um novo recurso no 
Databricks Runtime 10.3 e superior que permite visualizar e validar dados de 
origem antes de ingerir muitos arquivos dos repositérios de objetos na nuvem. 
Essas validagoes incluem: 


e se os dados puderem ser analisados 


* O esquema corresponde ao da tabela de destino ou se 0 esquema precisa 
ser evoluido 


¢ todas as restric¢des de nulidade e verificagao na tabela sao atendidas 


COPY INTO my example data 

FROM 's3://my-bucket/exampleData' 
FILEFORMAT = CSV 

VALIDATE 

COPY OPTIONS ('mergeSchema' = 'true') 


& databricks 


51 


O padréo para validagao de dados é analisar todos os dados no diretério de 
origem para garantir que nao haja problemas, mas as linhas retornadas para 
visualizagao sao limitadas. Uma alternativa é fornecer o numero de linhas para 
visualizar apd6s VALIDATE. 


O “mergeSchema” COPY_OPTION especifica que nao ha problema em 
desenvolver 0 esquema da tabela Delta de destino. A evolugao do esquema 
permite apenas a adicao de novas colunas e nao aceita alteracées de tipo de 
dados para colunas existentes. Em outros casos de uso, vocé pode omitir essa 
opgao se pretende gerenciar seu esquema de tabela mais estritamente, pois 
seu pipeline de dados pode ter requisitos rigorosos de esquema e talvez vocé 
nao queira evoluir o esquema o tempo todo. No entanto, nossa tabela Delta 

de destino no exemplo acima é uma tabela vazia e sem colunas no momento; 
portanto, é preciso especificar 0 “mergeSchema” COPY_OPTION neste caso. 


_coO ct _c2 _c3 _c4 _c5 
1 first_name last_name product_id subscription_id subscription_date last_updated 
2 Aemro Amare 101 1 2020-08-31 2022-12-21 19:23:23.609348 
3 Emma Liu 200 2 2020-08-30 2022-12-21 19:23:23.609348 
4 Amit Kara 50 3 2020-09-01 2022-12-21 19:23:23.609348 
5 Burak Yavuz 501 4 2020-09-02 2022-12-21 19:23:23.609348 


Figura 1: Saida do modo COPY INTO VALIDATE 
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2. Configurar COPY INTO 


Ao analisar os resultados de VALIDATE (veja a Figura 1), vocé pode notar 

que seus dados nao tém a aparéncia desejada. Nao ficou satisfeito por ter 
visualizado 0 conjunto de dados primeiro? A primeira coisa que vocé observa é 
que os nomes das colunas nao refletem o que esta especificado no cabegalho 
CSV. O que é pior, o cabegalho € mostrado como uma linha em seus dados. 
Vocé pode configurar o analisador CSV especificando FORMAT_OPTIONS. 
Vamos adiciona-los a seguir. 


COPY INTO my_ example data 
FROM 's3://my-bucket/exampleData' 
FILEFORMAT = CSV 


VALIDATE 

FORMAT OPTIONS ('header' = 'true', ‘inferSchema' = 'true', '‘mergeSchema' = 
"true') 

COPY OPTIONS ('mergeSchema' = 'true') 


Ao usar FORMAT OPTION, vocé pode dizer a COPY INTO para inferir os tipos 

de dados do arquivo CSV especificando a opgao inferSchema; caso contrario, 
todos os tipos de dados padrao sao STRINGs. Por outro lado, formatos de 
arquivo binario como AVRO e PARQUET nao precisam dessa opgao, pois definem 
seu préprio esquema. Outra opgao, “mergeSchema”, afirma que o esquema deve 
ser inferido em uma amostra abrangente de arquivos CSV em vez de apenas 
uma. A lista abrangente de opcodes especificas de formato pode ser encontrada 
na documentagao. 
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A Figura 2 mostra a saida de validagao de que o cabegalho foi analisado 
corretamente. 


Table v + 


first_name last_name product_id subscription_id subscription_date last_updated 
1 Aemro Amare 101 1 2020-08-31 2022-12-21T19:23:23.609+0000 
2 Emma Liu 200 2 2020-08-30 2022-12-21T19:23:23.609+0000 
3 Amit Kara 50 3 2020-09-01 2022-12-21T19:23:23.609+0000 
4 Burak Yavuz 501 4 2020-09-02 2022-12-21T19:23:23.609+0000 


Figura 2: Saida do modo COPY INTO VALIDATE com cabegalho habilitado e inferSchema 


3. Anexar dados a uma tabela Delta 


Agora que a visualizagao esta adequada, podemos remover a palavra-chave 
VALIDATE e executar 0 comando COPY INTO. 
COPY INTO my_example data 


FROM 's3://my-bucket/exampleData' 
FILEFORMAT = CSV 


FORMAT OPTIONS ('header' = 'true', 'inferSchema' = 'true', 'mergeSchema' 
"true' ) 
COPY OPTIONS ('mergeSchema' = 'true') 
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COPY INTO monitora 0 estado dos arquivos que 
foram ingeridos. Ao contrario de comandos como 
INSERT INTO, os usuarios obtém idempoténcia com 
COPY INTO, 0 que significa que nao obterao dados 
duplicados na tabela de destino ao executar COPY 
INTO varias vezes a partir dos mesmos dados 

de origem. 


COPY INTO pode ser executado uma vez, de forma 
ad hoc, e pode ser agendado com o Databricks 
Workflows. Embora COPY INTO nao oferega suporte 
a baixas laténcias para ingestao nativa, vocé pode 
aciona-lo por meio de orquestradores como o 
Apache Airflow. 
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4. Acesso seguro aos dados com COPY INTO 


COPY INTO oferece suporte ao acesso seguro de varias maneiras. Nesta secao, 
destacaremos duas novas opgdes que podem ser usadas no Databricks SQL e 
em notebooks de versoes recentes: 


Unity Catalog 

Com a disponibilidade geral do Unity Catalog da Databricks, vocé pode usar 
COPY INTO para ingerir dados em tabelas gerenciadas ou externas do Unity 
Catalog a partir de qualquer fonte e formato de arquivo suportado pelo COPY 
INTO. O Unity Catalog também adiciona novas opgoes para configurar 0 acesso 
seguro a dados brutos, permitindo usar locais externos do Unity Catalog ou 
credenciais de armazenamento para acessar dados no armazenamento de 


objetos na nuvem. Saiba mais sobre como usar COPY INTO com o Unity Catalog. 


Credenciais temporarias 

E se vocé nao tiver configurado o Unity Catalog ou o perfil da instancia? Que tal 
usar dados de um bucket de terceiros confiavel? Este € um recurso COPY INTO 
conveniente que permite ingerir dados com credenciais temporarias em linha 
para lidar com o caso de uso de ingestao em massa ad hoc. 


COPY INTO my example data 
FROM 's3://my-bucket/exampleDataPath' WITH ( 
CREDENTIAL (AWS ACCESS KEY = '...', AWS SECRET KEY = '... 
TOKEN = '...') 
) 
FILEFORMAT = CSV 


', AWS SESSION_ 
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5. Filtrar arquivos para ingestao 


E quanto a ingestao de um subconjunto de arquivos onde os nomes dos arquivos 
correspondem a um padrao? Vocé pode aplicar padrdoes de glob — um padrao 
de glob que identifica os arquivos a serem carregados no diretdrio de origem. Por 
exemplo, vamos filtrar e ingerir arquivos que contenham a palavra “raw_data” no 
nome do arquivo abaixo. 


COPY INTO my example data 
FROM 's3://my-bucket/exampleDataPath' 
FILEFORMAT = CSV 
PATTERN = '*raw_data*.csv' 
FORMAT OPTIONS ('header' = 'true') 


6. Ingerir arquivos em um periodo de tempo 


Na engenharia de dados, geralmente € necessario ingerir arquivos que foram 
modificados antes ou depois de um timestamp especifico. Dados entre 

dois timestamps também podem ser relevantes. As opgdes de formato 
“modifiedAfter” e “modifiedBefore” oferecidas pelo COPY INTO permitem que os 
usuarios ingiram dados de uma janela de tempo escolhida em uma tabela Delta. 


COPY INTO my example data 

FROM 's3://my-bucket/exampleDataPath' 

FILEFORMAT = CSV 

PATTERN = '*raw_data_*.csv' 

FORMAT OPTIONS('header' = 'true', ‘modifiedAfter' = '2022-09- 
12T10:53:11,000+0000' ) 
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7. Corrigir dados com a opgao de forcga 


Como o COPY INTO é idempotente por padrao, a execugao da mesma query 
nos mesmos arquivos de origem mais de uma vez nao tem efeito sobre a tabela 
de destino apés a execugao inicial. Vocé deve propagar as alteragdes na tabela 
de destino porque, em circunstancias reais, os arquivos de dados de origem 

no armazenamento de objetos na nuvem podem ser alterados para corregao 
em um momento posterior. Nesse caso, é possivel apagar primeiro os dados 

da tabela de destino antes de ingerir os arquivos de dados mais recentes da 
origem. Para essa operagao, vocé so precisa definir a opgao de cépia “force” 
como “true”. 


COPY INTO my_ example data 
FROM 's3://my-bucket/exampleDataPath' 
FILEFORMAT = CSV 


PATTERN = '*raw_data_2022*.csv' 
FORMAT OPTIONS('header' = 'true') 
COPY_OPTIONS ('force' = 'true') 
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8. Aplicar transformagoes simples 


E se vocé quiser renomear colunas? Ou se os dados de origem foram alterados 
e uma coluna anterior foi renomeada? Nao seria bom inserir esses dados como 
duas colunas separadas, mas como uma Unica coluna. Podemos aproveitar o 
comando SELECT em COPY INTO para fazer transformagées simples. 


COPY INTO demo.my example data 
FROM ( SELECT concat(first_name, " ", last _name) como full name, 
* EXCEPT (first_name, last_name) 
FROM 's3://my-bucket/exampleDataPath' 


) 
FILEFORMAT = CSV 


PATTERN = '*.csv' 
FORMAT OPTIONS('header' = 'true') 
COPY OPTIONS ('force' = 'true') 


9. Tratamento de erros e observabilidade com COPY INTO 


Tratamento de erros: 
que tal ingerir dados com problemas de corrupgao de arquivos? Exemplos 
comuns de corrupgao de arquivos sao: 

e Arquivos com um formato de arquivo incorreto 

e Falha ao descompactar 


° Arquivos ilegiveis (por exemplo, Parquet invalido) 
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A opgao de formato ignoreCorruptFiles de COPY INTO ajuda a ignorar esses 
arquivos durante o processamento. O resultado do comando COPY INTO retorna 
o numero de arquivos ignorados na coluna num_skipped_corrupt_files. Alem 
disso, esses arquivos corrompidos nao sao rastreados pelo estado de ingestao 
em COPY INTO, portanto, eles podem ser recarregados em uma execuGgao 
subsequente uma vez que a corrupgao é€ corrigida. Essa opgao esta disponivel 
no Databricks Runtime 11.0+. 


Vocé pode ver quais arquivos foram detectados como corrompidos executando 
COPY INTO no modo VALIDATE. 


COPY INTO my example data 
FROM 's3://my-bucket/exampleDataPath' 
FILEFORMAT = CSV 
VALIDATE ALL 
FORMAT OPTIONS('ignoreCorruptFiles' = 'true') 


Observabilidade: 

no Databricks Runtime 10,5, foi introduzida a coluna de metadados do arquivo 
para fornecer informagdes de metadados do arquivo de entrada, 0 que permite 
ao usuario monitorar e obter propriedades importantes dos arquivos ingeridos, 
como caminho, nome, tamanho e tempo de modificagao, consultando uma 
coluna STRUCT oculta chamada _metadados. Para incluir essas informagées no 
destino, vocé deve fazer referéncia explicitamente a coluna _metadados em sua 
query no COPY INTO. 


COPY INTO my_ example data 
FROM ( 
SELECT *, _metadata source_metadata FROM 's3://my-bucket/ 
exampleDataPath' 


) 
FILEFORMAT = CSV 
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Como ele se compara ao Auto Loader? 


COPY INTO € um comando simples e poderoso para usar quando o diretdrio de 
origem contém um pequeno numero de arquivos (ou seja, milhares de arquivos 
ou menos) e se vocé preferir SQL. Além disso, COPY INTO pode ser usado no 
JDBC para enviar dados para o Delta Lake como vocé achar melhor, um padrao 
comum de muitos parceiros de ingestao. Para ingerir um ndmero maior de 
arquivos em streaming e em batch, recomendamos usar o Auto Loader. Além 
disso, para um pipeline de dados moderno baseado na arquitetura medallion, 
recomendamos usar o Auto Loader nos pipelines do Delta Live Tables, 
aproveitando os recursos avangados de tratamento automatico de erros, 
controle de qualidade, linnagem de dados e definigao de expectativas em uma 
abordagem declarativa. 


Como comegar? 


Para comegar, vocé pode acessar o editor de queries do Databricks SQL, 
atualizar e executar o exemplo de comandos SQL para ingerir a partir de seus 
armazenamentos de objetos em nuvem. Confira as opgées no No. 4 para 
estabelecer acesso seguro aos seus dados para consulta-los no Databricks 
SQL. Para se familiarizar com o COPY INTO no Databricks SQL, vocé também 
pode seguir este tutorial de inicio rapido. 


Como alternativa, vocé pode usar este notebook nos workspaces de Data 
Science e Data Engineering e Machine Learning para aprender a maioria dos 
recursos COPY INTO deste blog, em que os dados de origem e as tabelas Delta 
de destino sao gerados no DBFS. 


Veja mais tutoriais sobre COPY INTO aqui. 
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Simplificar a captura de dados de alteragoes com o Delta Live Tables da Databricks 


por MOJGAN MAZOUCHI 
25 de abril de 2022 


Este guia demonstrara como aproveitar a captura de dados de alteragées 

nos pipelines do Delta Live Tables para identificar novos registros e capturar 
alteragées feitas no conjunto de dados em seu data lake. Os pipelines do Delta 
Live Tables permitem desenvolver pipelines de dados escalaveis, confiaveis e de 
baixa laténcia, enquanto executa a captura de dados de alteragées em seu data 
lake com os recursos de compute minimos necessarios e o tratamento continuo 
de dados fora de ordem. 


Observagao: recomendamos seguir a Introdugao ao Delta Live Tables, 
que explica como criar pipelines escalaveis e confiaveis usando 
o Delta Live Tables (DLT) e suas definigées de ETL declarativas. 


Hist6rico da captura de dados de alteragées 


A captura de dados de alteragées (CDC) 6 um processo que identifica e 
captura alteragées incrementais (exclus6es, insergdes e atualizagdes de dados) 
em bancos de dados, como rastreamento de status de clientes, pedidos ou 
produtos para aplicativos de dados quase em tempo real. O CDC proporciona 

a evolugao dos dados em tempo real, processando-os de forma continua e 
incremental a medida que ocorrem novos eventos. 
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Uma vez que mais de 80% das organizagoes planejam implementar estratégias 
multicloud até 2025, é fundamental escolher a abordagem certa para sua 
empresa que permita centralizagao perfeita em tempo real de todas as 
alteragdes de dados em seu pipeline de ETL em varios ambientes. 


Ao capturar eventos de CDC, os usuarios do Databricks podem materializar 
novamente a tabela de origem como Delta Table no Lakehouse e executar uma 
analise sobre ela, aleém de conseguir combinar dados com sistemas externos. 

O comando MERGE INTO no Delta Lake no Databricks permite que os clientes 
atualizem e excluam registros de forma eficiente em seus data lakes. Vocé pode 
saber mais sobre o tépico anterior aqui. Esse € um caso de uso comum em que 
observamos muitos dos clientes do Databricks usando o Delta Lakes para realizar 
e manter seus dados atualizados com dados de negécios em tempo real. 


Embora o Delta Lake fornega uma solugao completa para sincronizagao de CDC 
em tempo real em um data lake, agora temos o prazer de anunciar o recurso de 
captura de dados de alteragoes no Delta Live Tables que torna sua arquitetura 
ainda mais simples, eficiente e escalavel. O DLT permite que os usuarios ingiram 
dados de CDC sem problemas usando SQL e Python. 


As solugées CDC anteriores com tabelas Delta usavam a operagao MERGE INTO, 
que exige a ordenagaéo manual dos dados para evitar falhas quando varias linhas 
do conjunto de dados de origem coincidem ao tentar atualizar as mesmas 
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linhas da tabela Delta de destino. Para lidar com os dados fora de ordem, era 
necessaria uma etapa extra para pré-processar a tabela de origem usando 

uma implementagaéo de ForEachBatch para eliminar a possibilidade de varias 
correspondéncias, mantendo somente a alteragao mais recente para cada 
chave (veja o exemplo de captura dados de alteragées). A nova operagdo APPLY 
CHANGES INTO em pipelines DLT lida de forma automatica e perfeita com dados 
fora de ordem, sem a necessidade de intervengao manual de data engineering . 


CDC com Delta Live Tables do Databricks 


Neste blog, demonstraremos como usar 0 comando APPLY CHANGES INTO 

nos pipelines do Delta Live Tables para um caso de uso comum do CDC em 

que os dados do CDC vém de um sistema externo. Ha uma variedade de 
ferramentas de CDC disponivel, como Debezium, Fivetran, Qlik Replicate, Talend 
e StreamSets. Embora as implementacées especificas sejam diferentes, essas 
ferramentas geralmente capturam e registram o hist6rico de alteragdes de 
dados nos registros; os aplicativos downstream consomem esses registros do 
CDC. Em nosso exemplo, os dados sao colocados no armazenamento de objetos 
na nuvem a partir de uma ferramenta CDC, como Debezium, Fivetran etc. 


Temos dados de varias ferramentas CDC que entram em um armazenamento 
de objetos na nuvem ou em uma fila de mensagens como o Apache Kafka. 
Normalmente, o CDC é usado em uma ingestao do que chamamos de 
arquitetura medallion. A arquitetura medallion se refere ao design de dados 
usado para organizar logicamente os dados em um Lakehouse, que visa 
melhorar de forma incremental e progressiva a estrutura e a qualidade dos 
dados a medida que fluem por camada da arquitetura. O Delta Live Tables 
permite aplicar perfeitamente as alteragdes dos feeds do CDC Aas tabelas 

do seu Lakehouse; a combinagao dessa funcionalidade com a arquitetura 
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medallion permite que as alteragdes incrementais fluam facilmente pelas 
cargas de trabalho analiticas em escala. O uso do CDC em conjunto com a 
arquitetura medallion oferece varios beneficios aos usuarios, ja que sd é preciso 
processar dados alterados ou adicionados. Assim, ele permite que os usuarios 
mantenham as tabelas Gold atualizadas de forma econdémica com os dados de 
negdcios mais recentes. 


OBSERVAGAO: 0 exemplo aqui se aplica 4s vers6es SQL e Python do CDC 
e também sobre uma forma especifica de usar as operagoées; para avaliar 
variagdes, consulte a documentagao oficial aqui. 


Pré-requisitos 


Para aproveitar ao maximo este guia, vocé deve conhecer pelo menos 
o basico sobre: 


¢ SQL ou Python 
Delta Live Tables 


¢ Desenvolvimento de pipelines ETL e/ou trabalho com sistemas de Big Data 
e Notebooks e clusters interativos da Databricks 


e Vocé deve ter acesso a um Databricks Workspace com permiss6es para criar 
novos clusters, executar jobs e salvar dados em um local no armazenamento 
externo de objetos na nuvem ou no DBFS 


¢ Para o pipeline que estamos criando neste blog, é preciso selecionar 
a edicgao “Advanced” do produto, que oferece suporte a aplicagao de 
restrig¢des de qualidade de dados 
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Conjunto de dados 


Aqui estamos consumindo dados de CDC realistas de um banco de dados 
externo. Neste pipeline, usaremos a biblioteca Faker para gerar o conjunto de 
dados que uma ferramenta CDC como o Debezium pode produzir e trazer para 
oO armazenamento em nuvem para a ingestao inicial no Databricks. Usando o 
Auto Loader, carregamos incrementalmente as mensagens do armazenamento 
de objetos na nuvem e as armazenamos na tabela Bronze a medida que 
armazena as mensagens brutas. As tabelas Bronze destinam-se a ingestao 

de dados que permitem o acesso rapido a uma Unica fonte de verdade. Em 
seguida, executamos APPLY CHANGES INTO da tabela de camada Bronze limpa 
para propagar as atualizagoes downstream para a tabela Silver. A medida que 
os dados fluem para as tabelas Silver, geralmente eles se tornam mais refinados 
e otimizados (“apenas o suficiente”) para fornecer a uma empresa uma visdo de 
todas as suas principais entidades de negocios. Veja 0 diagrama abaixo. 


i Delta Live Table Pipeline f 

ay (Streaming Source) 
Extract cde | | | | | 

MySQL External tools like | 
Debezium | | | | | 

Fivetran -— 1 
External database _ | iva ee a | | | 

clients : | 

mt A 
products AG | | commu,  customer_bronze — cystomer_bronze_clean_v customer_silver | 
Hem ty. le are as aes Re ee es eee ees l 
transactions ES Bee ee ee ES ae Se ee eee Oe eee ee Se Re ee es 
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Este blog tem por foco um exemplo simples que exige uma mensagem JSON com 
quatro campos de nome, e-mail, endereco e id do cliente juntamente com os 
dois campos: operation (que armazena o cédigo de operagdo (DELETE, APPEND, 
UPDATE, CREATE) e operation_date (que armazena a data e o timestamp para o 
registro de cada agao de operagao) para descrever os dados alterados. 


Para gerar um conjunto de dados de amostra com os campos acima, estamos 
usando um pacote Python que gera dados falsos, Faker. Vocé pode encontrar o 
notebook relacionado a esta segao de geragao de dados aqui. Neste notebook, 
fornecemos 0 nome € o local de armazenamento para gravar os dados 
gerados la. Estamos usando a funcionalidade DBFS do Databricks; consulte 

a documentagao DBFS para saber mais sobre como funciona. Em seguida, 
usamos uma fungao do PySpark definida pelo usuario para gerar 0 conjunto 

de dados sintéticos para cada campo e gravamos os dados de volta ao local 
de armazenamento definido, que iremos nos referir em outros notebooks para 
acessar 0 Conjunto de dados sintéticos. 


Ingerir o conjunto de dados brutos usando o Auto Loader 


De acordo com 0 paradigma da arquitetura medallion, a camada Bronze mantém 
a qualidade dos dados brutos. Neste estagio, podemos ler incrementalmente 
novos dados usando o Auto Loader de um local no armazenamento em nuvem. 
Aqui estamos adicionando 0 caminho para nosso conjunto de dados gerado a 
secao de configuragao nos ajustes do pipeline, o que nos permite carregar o 
caminho de origem como uma variavel. Portanto, agora nossa configuragao nos 
ajustes do pipeline fica assim: 


"configuration": { 
"source": "/tmp/demo/cdc_raw" 


} 
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Depois, carregamos esta propriedade de configuragaéo em nossos notebooks. 


Vamos dar uma olhada na tabela Bronze que iremos ingerir, a. Em SQL, e b. 
Usando Python 


A. SQL 


SET spark.source; 

CREATE STREAMING LIVE TABLE customer_bronze 

( 

address string, 

email string, 

id string, 

firstname string, 

lastname string, 

operation string, 

operation date string, 

_rescued_ data string 

) 

TBLPROPERTIES ("quality" = "bronze" ) 

COMMENT "Novos dados de clientes ingeridos de forma incremental a partir 
da zona de destino do armazenamento de objetos na nuvem" 

AS 

SELECT * 

FROM cloud _files("${source}/customers", "json", map("cloudFiles. 
inferColumnTypes", "true")); 
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B. PYTHON 


import dlt 
from pyspark.sql.functions import * 
from pyspark.sql.types import * 


source = spark.conf.get("source" ) 


@d1t.table(name="customer_bronze", 
comment = "Novos dados do cliente ingeridos 

incrementalmente da zona de aterrissagem do armazenamento de objetos na 
nuvem", 

table_properties={ 

"quality": "bronze" 

; 

) 


def customer_bronze(): 
return ( 
spark.readStream.format("cloudFiles") \ 
-option("cloudFiles.format", "json") \ 
-option("cloudFiles.inferColumnTypes", "true") \ 
-load(£"{source}/customers" ) 


As declaragdes acima usam o Auto Loader para criar uma tabela de streaming 
ao vivo chamada customer_bronze a partir de arquivos json. Ao usar o 

Auto Loader no Delta Live Tables, vocé nao precisa fornecer nenhum local 
para esquema ou ponto de verificagao, pois esses locais serao gerenciados 
automaticamente pelo pipeline DLT. 


O Auto Loader fornece uma fonte de Structured Streaming chamada cloud_ 
files no SQL e cloudFiles no Python, que usa um caminho e um formato de 
armazenamento em nuvem como parametros. 


Para reduzir os custos de compute, recomendamos executar 0 pipeline DLT no 
modo Triggered como um micro-batch, supondo que vocé nao tenha requisitos 
de laténcia muito baixa. 
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Expectativas e dados de alta qualidade 


Na préxima etapa para criar um conjunto de dados de alta qualidade, 
diversificado e acessivel, impomos critérios de expectativa de verificagao de 
qualidade usando restri¢gdes. Atualmente, uma restrigao pode ser reter, soltar 
ou falhar. Para mais detalhes, consulte aqui. Todas as restrig6es sao registradas 
para permitir um monitoramento de qualidade simplificado. 


A. SQL 


CREATE TEMPORARY STREAMING LIVE TABLE customer_bronze_clean_v( 
CONSTRAINT valid_id EXPECT (id IS NOT NULL) ON VIOLATION DROP ROW, 
CONSTRAINT valid_address EXPECT (address IS NOT NULL), 

CONSTRAINT valid_operation EXPECT (operation IS NOT NULL) ON VIOLATION 

DROP ROW 


) 


TBLPROPERTIES ("quality" = "silver") 
COMMENT "Visualizagao do cliente Bronze limpa (ou seja, o que se tornara 
Silver)" 


AS SELECT * 
FROM STREAM(LIVE.customer_bronze) ; 


B. PYTHON 


@dlt.view(name="customer_ bronze clean v", 
comment="Visualiza¢g&do do cliente Bronze limpa (ou seja, o que se tornara 
Silver) ") 


@dlt.expect_or drop("valid_id", "id IS NOT NULL") 
@dlt.expect ("valid_address", "address IS NOT NULL") 
@dlt.expect_or_drop("valid_operation", "operation IS NOT NULL") 


def customer _bronze clean v(): 


return dlt.read_stream("customer bronze") \ 
-select("address", "email", "id", "firstname", "lastname", 
“operation”, “operation date”, " rescued data™) 


&Y databricks 


Usar a declaragao APPLY CHANGES INTO para propagar alteragoes na 
tabela de destino downstream 


Antes de executar a consulta Apply Changes Into, devemos garantir que 
exista uma tabela de streaming de destino na qual queremos manter os dados 
mais atualizados. Se nao existir, precisamos criar uma. As células abaixo sao 
exemplos de criagao de uma tabela de streaming de destino. Observe que, 

no momento da publicagao deste blog, a instrugao de criagao da tabela de 
streaming de destino é necessAria junto com a consulta Apply Changes Into e 
ambas precisam estar presentes no pipeline — caso contrario, havera falha na 
query de criagao da tabela. 


A. SQL 


CREATE STREAMING LIVE TABLE customer silver 
TBLPROPERTIES ("quality" = "silver") 
COMMENT "Clientes limpos e combinados"; 


B. PYTHON 


dlt.create_target_table(name="customer_silver", 
comment="Clientes limpos e mesclados", 
table properties={ 
"quality": "silver" 


} 
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Agora que temos uma tabela de streaming de destino, podemos propagar 
alteragoes na tabela de destino downstream usando a consulta Apply Changes 
Into. Enquanto o feed do CDC vem com eventos INSERT, UPDATE e DELETE, o 
comportamento padrao da DLT é aplicar eventos INSERT e UPDATE de qualquer 
registro no conjunto de dados de origem correspondente em chaves primarias 
e sequenciado por um campo que identifica a ordem dos eventos. Mais 
especificamente, ele atualiza qualquer linha na tabela de destino existente que 
corresponda as Chaves primarias ou insere uma nova linha quando um registro 
correspondente nao existe na tabela de streaming de destino. Podemos 

usar APPLY AS DELETE WHEN no SQL ou seu argumento apply_as_deletes 
equivalente em Python para manipular eventos DELETE. 


Neste exemplo, usamos “id” como minha chave primaria, que identifica 
exclusivamente os clientes e permite que os eventos do CDC sejam aplicados 
aos registros de clientes identificados na tabela de streaming de destino. Como 
“operation_date” mantém a ordem légica dos eventos do CDC no conjunto 

de dados de origem, usamos “SEQUENCE BY operation_date” no SQL, ou 

seu equivalente “sequence_by = col(“operation_date”)” no Python para lidar 
com eventos de mudanga que chegam fora de ordem. Lembre-se de que o 
valor de campo que usamos com SEQUENCE BY (ou sequence_by) deve ser 
exclusivo entre todas as atualizagoes da mesma chave. Na maioria dos casos, a 
sequéncia por coluna sera uma coluna com informagées de timestamp. 


Por fim, usamos “COLUMNS * EXCEPT (operation, operation_date, _rescued_data)” 


nea 


no SQL ou seu equivalente “except_column_list”= [“operation”, “operation_date”, 


a“ mow 


_rescued_data”] no Python para excluir trés colunas de “operation”, “operation_ 
date”, “_rescued_data” da tabela de streaming de destino. Por padrao, todas as 
colunas sao incluidas na tabela de streaming de destino, quando nao especificamos 
a clausula “COLUMNS”. 


&Y databricks 


62 


A. SQL 


APPLY CHANGES INTO LIVE.customer_silver 
FROM stream(LIVE.customer_bronze_clean_v) 
KEYS (id) 
APPLY AS DELETE WHEN operation = "DELETE" 
SEQUENCE BY operation_date 
COLUMNS * EXCEPT (operation, operation date, 
_rescued_data); 


B. PYTHON 


dlt.apply changes ( 
target = "customer silver", 
source = "customer bronze clean v", 
keys = ["id"], 
sequence by = col("operation date"), 
apply as deletes = expr("operation = 'DELETE'"), 
except _column_list = ["operation", "operation date", " rescued data"]) 


Para conferir a lista completa de clausulas disponiveis, consulte aqui. 


Observe que, no momento da publicagao deste blog, uma tabela que leia a 
partir do destino de uma query APPLY CHANGES INTO ou fungao apply_changes 
deve ser uma tabela ao vivo e nao pode ser uma tabela de streaming ao vivo. 


Um notebook SQL e Python esta disponivel para referéncia nesta segao. Agora 
que temos todas as células prontas, vamos criar um pipeline para ingerir dados 
do armazenamento de objetos em nuvem. Abra Jobs em uma nova tab ou janela 
no workspace e selecione “Delta Live Tables”. 
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O pipeline associado a este blog tem as seguintes configura¢gées de pipeline DLT: 


"clusters": [ 
{ 
"label": "default", 
"num workers": 1 
} 
1, 
"development": true, 
"continuous": false, 


"edition": "advanced", 
"photon": false, 
"libraries": [ 


{ 


"notebook": { 
"path":"/Repos/mojgan.mazouchi@databricks.com/Delta-Live-Tables/ 
notebooks/1-CDC_DataGenerator" 

} 

hy 
{ 


"notebook": { 
"path":"/Repos/mojgan.mazouchi@databricks.com/Delta-Live-Tables/ 
notebooks/2-Retail_DLT_CDC_sql" 

} 

} 
], 


"name": "CDC blog", 
"storage": "dbfs:/home/mydir/myDB/dlt_ storage", 
"configuration": { 
"source": "/tmp/demo/cdc_raw", 
"pipelines.applyChangesPreviewEnabled": "true" 
hy 
"target": "my database" 
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a) 


Selecione “Criar pipeline” para criar um novo pipeline 
Especifique um nome, como “Pipeline de CDC de Varejo” 


Especifique os caminhos do notebook que vocé ja criou anteriormente, um 
para o conjunto de dados gerado usando 0 pacote Faker e outro para a 
ingestao dos dados gerados no DLT. O segundo caminho do notebook pode 
se referir ao notebook escrito em SQL ou Python, dependendo da linguagem 
de sua escolha. 


Para acessar os dados gerados no primeiro notebook, adicione 0 caminho do 
conjunto de dados na configuragao. Aqui armazenamos os dados em “/tmp/ 
demo/cdc_raw/customers”, depois definimos “source” como “/tmp/demo/ 
cdc_raw/" para referenciar “source/customers” em nosso segundo notebook.” 


Especifique o Target (que é opcional e se refere ao banco de dados de 
destino), onde vocé pode consultar as tabelas resultantes do seu pipeline 


Especifique o local de armazenamento no seu armazenamento de objetos 
(opcional) para acessar os conjuntos de dados produzidos pelo DLT e os 
registros de metadados do seu pipeline 


Defina o Modo de pipeline como Acionado. No modo Acionado, 0 pipeline 
DLT consumira novos dados na origem de uma so vez e, uma vez concluido 
oO processamento, encerrara 0 recurso de compute automaticamente. 
Vocé pode alternar entre os modos Acionado e Continuo ao editar as 
configurag6ées de pipeline. Definir “continuous”: false no JSON equivale a 
definir o pipeline para o modo Acionado. 


Para esta carga de trabalho, vocé pode desabilitar o dimensionamento 
automatico em Opg¢oes do Autopilot e usar somente um cluster de 
worker. Para cargas de trabalho de produgao, recomendamos habilitar 
o dimensionamento automatico e definir o numero maximo de workers 
necessarios para o tamanho do cluster. 


Selecione “Iniciar” 


10. Seu pipeline ja esta criado e funcionando! 
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10/2/2022, 8:05:17 PM - @ Completed v 


> Status (2) Completed 
Start time 10/2/2022, 8:08:53 PM 
=? 
Duration 8s 
= customer_bronze Q ® customer_bronze_.. 2 © customer_silver 2) 
Completed » 6s , Completed | 45 Complated - &s Comment Clean, merged customers 


@ 100K © 0 eo © 12K e- 8. 


Schema 


ua address: string 
email: string 
aes |. id; string 
firstname: string 
- lastname: string 


Create Pipeline 


* Product Edition 
Advanced 

Help me choose 

” Pipeline Name 


Retail_CDC_in_DLT_demo 


* Notebook Libraries @ 


/Delta-Live-Tables/notebooks/1-~CDC_DataGenerator 


Add notebook library 
» 


Configuration 


Add configuration 


Target @ 


Observabilidade da linhagem do pipeline DLT 
e monitoramento da qualidade dos dados 


Todos os logs do pipeline DLT sAo armazenados no local de armazenamento do 
pipeline. Vocé pode especificar o local de armazenamento somente quando 
estiver criando seu pipeline. Observe que, apés a criagao do pipeline, vocé nao 
podera mais modificar o local de armazenamento. 
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Vocé pode conferir nossa analise aprofundada anterior sobre 0 assunto aqui. 
Experimente este notebook para ver a observabilidade do pipeline e o 
monitoramento da qualidade dos dados no exemplo de pipeline DLT associado 
a este blog. 


Conclusao 


Neste blog, mostramos como facilitamos para os usuarios a implementagao 
eficiente da captura de dados de alteragées (CDC) em sua plataforma de lakehouse 
com o Delta Live Tables (DLT). O DLT oferece controles de qualidade integrados 
com visibilidade profunda das operagoes do pipeline, observando a linhagem do 
pipeline, o esquema de monitoramento e as verificagdes de qualidade em cada 
etapa do pipeline. O DLT oferece suporte ao tratamento automatico de erros e 
ao melhor recurso de dimensionamento automatico da categoria para cargas de 
trabalho de streaming, 0 que permite que os usuarios tenham dados de qualidade 
com Os recursos ideais necessarios para a carga de trabalho. 


Agora os engenheiros de dados podem implementar facilmente o CDC com 
uma nova APPLY CHANGES INTO API declarativa com DLT em SQL ou Python. 
Esse novo recurso permite que seus pipelines ETL identifiquem facilmente as 
alteragdes e apliquem essas alteragdes em dezenas de milhares de tabelas com 
suporte de baixa laténcia. 


Pronto para comegar e experimentar vocé mesmo o CDC no Delta 
Live Tables? 

Assista a este webinar para saber como o Delta Live Tables simplifica a 
complexidade da transformagao de dados e do ETL e leia o documento 
Captura de dados de alteragdes com o Delta Live Tables, github oficial 
e siga as etapas deste video para criar seu pipeline! 
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Praticas recomendadas para compartilhamento de dados entre governos 


por MILOS COLIC, PRITESH PATEL, ROBERT WHIFFIN, RICHARD JAMES WILSON, 


MARCELL FERENCZ e EDWARD KELLY 
21 de fevereiro de 2023 


A troca de dados governamentais é a pratica de compartilhar dados entre 
diferentes 6érgaos governamentais e, muitas vezes, parceiros em setores 
comerciais. O governo pode compartilhar dados por varias razOes, como 
melhorar a eficiéncia das operagdes governamentais, fornecer melhores 
servigos ao publico ou apoiar a pesquisa e a formulagao de politicas. Além 
disso, a troca de dados no setor publico pode envolver o compartilhamento 
com o setor privado ou o recebimento de dados do setor privado. As 
consideragoes abrangem varias jurisdigdes e em quase todos os setores. Neste 
blog, abordaremos as necessidades divulgadas como parte das estratégias 
de dados nacionais e como as tecnologias modernas, particularmente 

Delta Sharing, Unity Catalog e clean rooms, podem ajudar vocé a projetar, 
implementar e gerenciar um ecossistema de dados sustentavel e preparado 
para o futuro. 


Compartilhamento de dados e setor pUublico 
“O milagre é este: quanto mais compartilhamos, mais temos.” — Leonard Nimoy.” 


Esta provavelmente é a citagao sobre compartilhamento que se aplica mais 
profundamente ao tépico de compartilhamento de dados, na medida em 
que o objetivo de compartilhar os dados € criar novas informagées, novos 
insights e novos dados. A importancia do compartilhamento de dados é 
ainda mais acentuada no contexto governamental, onde a federagaéo entre 
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departamentos permite maior foco. Ainda assim, a mesma federagao apresenta 
desafios em relacao a integridade, qualidade, acesso, seguranga, controle, 
equidade dos dados etc. Esses desafios estao longe de ser triviais e exigem 
uma abordagem estratégica e multifacetada para serem abordados de forma 
adequada. Tecnologia, pessoas, processos, estruturas legais, entre outros, 
exigem consideragao dedicada ao projetar um ecossistema robusto de 
compartilhamento de dados. 


A National Data Strategy (NDS) do governo do Reino Unido descreve cinco 
miss6es acionaveis por meio das quais podemos materializar o valor dos dados 
para beneficio do cidadao e de toda a sociedade. 


Opportunities 
Services 
Actions 


Mission 1 Mission 2 Mission 3 Mission 4 Mission 5 


Other actions aligned to pillars 


Pillars of effective use 
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Nao surpreende que cada uma das miss6es esteja fortemente relacionada ao 
conceito de compartilhamento de dados ou, mais amplamente, ao acesso a 
dados dentro e fora dos departamentos governamentais: 


1. Desbloquear o valor dos dados em toda a economia: a missao principal da 
NDS é afirmar o governo e os reguladores como facilitadores da extragao de 
valor dos dados por meio da adogao das praticas recomendadas. Estima-se 
que a economia de dados do Reino Unido esteja préxima de £125 bilhédes em 
2021 com uma tendéncia ascendente. Nesse contexto, é essencial entender 
que os dados abertos coletados pelo governo e fornecidos podem ser 
cruciais para enfrentar muitos dos desafios em todos os setores. 


Por exemplo, as seguradoras podem avaliar melhor o risco de garantir 
propriedades, ingerindo e integrando areas de inundagao fornecidas 

pela DEFRA. Por outro lado, os investidores do mercado de capitais 
poderiam entender melhor o risco de seus investimentos, ingerindo e 
integrando o Indice de taxa de inflacdo pela ONS. Por outro lado, é crucial 
que os reguladores tenham padrées bem definidos de acesso a dados e 
compartilhamento de dados para conduzir suas atividades regulatérias. Essa 
clareza realmente empodera os atores econdmicos que interagem com os 
dados do governo. 
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Garantir um regime de dados pr6-crescimento e confiavel: o principal 
aspecto da segunda missao é a confianga nos dados ou, mais amplamente, a 
adesao as normas de qualidade dos dados. As consideragées de qualidade 
de dados sao ainda mais relevantes para casos de uso de compartilhamento 
e troca de dados em que levamos em conta todo 0 ecossistema de uma s6 
vez, e as implicagées de qualidade transcendem os limites da nossa propria 
plataforma. E justamente por isso que temos que adotar a “sustentabilidade 
de dados”. O que queremos dizer com produtos de dados sustentaveis sao 
produtos de dados que aproveitam as fontes existentes em detrimento da 
reinvengao dos mesmos/similares ativos, acumulo de dados desnecessarios 
(poluentes de dados) e que antecipam usos futuros. 


O compartilhamento de dados nao controlado e ilimitado pode afetar 
negativamente a qualidade dos dados e prejudicar 0 crescimento e o valor 
dos dados. A qualidade de como os dados sao compartilhados deve ser uma 
consideragao fundamental das estruturas de qualidade de dados. Por essa 
razao, exigimos um conjunto sdlido de padroées e praticas recomendadas 
para o compartilhamento de dados com governanga e garantia de qualidade 
embutidas no processo e nas tecnologias. S6 assim podemos garantir 

a sustentabilidade dos nossos dados e garantir um regime de dados de 
confianga pré-crescimento. 
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3. Transformar o uso de dados pelo governo para impulsionar a eficiéncia 


e melhorar os servigos publicos: — “Até 2025, os ativos de dados serao 
organizados e tratados como produtos, independentemente de serem 
usados por equipes internas ou clientes externos... Os produtos de dados 
evoluem continuamente de maneira agil para atender as necessidades 

dos consumidores... esses produtos fornecem solugées de dados que 
podem ser usadas de maneira mais facil e repetida para atender a varios 
desafios de negocios e reduzir o tempo e o custo do fornecimento de novos 
recursos orientados por IA.” — A empresa orientada por dados de 2025, pela 
McKinsey. A IA e o ML podem ser poderosos facilitadores da transformagao 
digital tanto para os setores publico como privado. 


IA, ML, relat6érios e painéis sAo apenas alguns exemplos de produtos e servicos 
de dados que extraem valor dos dados. A qualidade dessas solugcées reflete- 
se diretamente na qualidade dos dados usados para construi-las e na nossa 
capacidade de acessar e aproveitar os ativos de dados disponiveis, tanto 
interna como externamente. Embora exista uma grande quantidade de dados 
disponiveis para construirmos novas solugées inteligentes para impulsionar a 
eficiéncia para melhores processos, melhor tomada de decisées e melhores 
politicas, também ha inumeras barreiras que podem prender os dados, 
como sistemas legados, silos de dados, padr6ées fragmentados, formatos 
proprietarios etc. Modelar solugées de dados como produtos de dados e 
padroniza-los em um formato unificado nos permite abstrair essas barreiras 
e aproveitar verdadeiramente o ecossistema de dados. 
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Garantir a seguranga e a resiliéncia da infraestrutura da qual os dados 
dependem: pensando na visao do ano 2025 — isso nao esta muito longe 

do presente e mesmo em um futuro nao tao distante, seremos obrigados 

a repensar nossa abordagem aos dados, mais especificamente — qual éa 
nossa infraestrutura de cadeia de fornecimento digital/infraestrutura de 
compartilhamento de dados? Dados e ativos de dados sao produtos e devem 
ser gerenciados como tais. 


Se os dados sao um produto, precisamos de uma forma coerente e unificada 
de fornecer esses produtos. Se os dados forem usados em todos os setores 

e nos setores publico e privado, precisamos de um protocolo aberto que 
impulsione a adogaéo e a geracao de habitos. Para motivar a adogao, as 
tecnologias que usamos devem ser resilientes, robustas, confiaveis e utilizaveis 
por/para todos. A dependéncia do fornecedor, da plataforma ou da nuvem sao 
limites para concretizar essa visao. 


Promover o fluxo internacional de dados: — a troca de dados entre 
jurisdig6es e governos provavelmente sera uma das aplicagées mais 
transformadoras dos dados em escala. Alguns dos desafios mais dificeis do 
mundo dependem da troca eficiente de dados entre governos — prevengao 
de atividades criminosas, atividades contraterroristas, metas de emissao 
nao zero, comércio internacional, e essa lista vai longe. Algumas etapas nesta 
diregao ja sao realidade: o governo federal dos EUA e 0 governo do Reino 
Unido concordaram em trocar dados para combater atividades criminais 
graves. Esse € um exemplo real de promogao de dados de fluxo internacional 
e uso de dados para 0 bem. E imperativo que, para esses casos de uso, 
abordemos o compartilhamento de dados de um angulo de seguranga em 
primeiro lugar. Os padr6ées e protocolos de compartilhamento de dados 
precisam aderir as praticas recomendadas de seguranga e privacidade. 
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Embora originalmente construido com foco no governo do Reino Unido e em 
como integrar melhor os dados como um ativo-chave de um governo moderno, 


esses conceitos se aplicam em um contexto mais amplo do setor publico global. 


No mesmo sentido, 0 governo federal dos EUA propés a Estratégia Federal de 
Dados como uma colegao de principios, praticas, etapas de agao e cronograma 
através dos quais 0 governo pode aproveitar todo o valor dos dados federais 
para missao, servigo e bem publico. 


Federal Data Strategy Framework 


Mission Statement 


The mission of the Federal Data Strategy is to leverage the full value of Federal data for mission, service, and the 
public good by guiding the Federal Government in practicing ethical governance, conscious design, and a learning culture. 


Principles 


Practices 


Aspirational goals fora 
5- to 10-year horizon to 
further the principles 


Action Steps 


Activities in the 
2020 Action Plan chosen to 
implement the practices 


Timeless, enduring 
guide for agencies 


Os principios séo agrupados em trés tdpicos principais: 


¢ Governanga ética — Dentro do dominio da ética, o compartilhamento 
de dados é uma ferramenta fundamental para promover transparéncia, 
responsabilidade e explicabilidade da tomada de decisées. E praticamente 
impossivel manter a ética sem alguma forma de auditoria conduzida por 
uma parte independente. A troca de dados (e metadados) é um facilitador 
critico para processos robustos continuos que garantem que estamos 
usando os dados para 0 bem e que estamos usando os dados em que 
podemos confiar. 
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¢ Design consciente — Esses principios estao fortemente alinhados coma 
ideia de sustentabilidade de dados. As diretrizes promovem 0 pensamento 
futuro em relagao a usabilidade e interoperabilidade dos dados e principios 
de design centrados no usuario de produtos de dados sustentaveis. 


¢ Cultura de aprendizagem — O compartilhamento de dados, ou 
compartilhamento de conhecimento alternativo, tem um papel importante 
na criagao de um ecossistema de aprendizagem escalavel e cultura 
de aprendizagem. Os dados s@o a frente e 0 centro da sintese do 
conhecimento e, a partir de um angulo cientifico, os dados comprovam o 
conhecimento factual. Outro componente critico do conhecimento é o “Por 
qué?”, e precisamos dos dados para abordar esse componente de qualquer 
decisao que tomamos, qual politica aplicar, quem sancionar, quem apoiar 
com concessées, como melhorar a eficiéncia dos servigos governamentais, 
como atender melhor aos cidadaos e a sociedade. 


Em contraste com a analise qualitativa discutida anteriormente do valor do 
compartilhamento de dados entre governos, a Comissao Europeia prevé que 

o valor econémico da economia de dados europeia exceda €800 bilhdes 

até 2027 — aproximadamente 0 mesmo tamanho da economia holandesa 

em 2021! Além disso, eles preveem mais de 10 milhées de profissionais de 
dados somente na Europa. A tecnologia e a infraestrutura para dar suporte a 
sociedade de dados precisam ser acessiveis a todos, interoperaveis, extensiveis, 
flexiveis e abertas. Imagine um mundo em que vocé precisa de um caminhao 
diferente para transportar produtos entre diferentes armazéns, pois cada 
estrada exige um conjunto diferente de pneus — toda a cadeia de suprimentos 
entraria em colapso. Quando se trata de dados, muitas vezes vivenciamos o 
paradoxo “um conjunto de pneus para uma Unica estrada”. Foram propostos 
APIs e protocolos de troca de dados de repouso, mas nao conseguiram atender 
a necessidade de simplicidade, facilidade de uso e custo de expansado com o 
numero de produtos de dados. 
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Delta Sharing — a nova estrada 
de dados 


O Delta Sharing oferece um protocolo aberto para 
o compartilhamento seguro de dados em qualquer 
plataforma de compute. O protocolo é baseado no 
formato de dados Delta e nao depende da nuvem 
que vocé escolher. 


Delta € um formato de dados de cédigo aberto que 
evita a dependéncia de fornecedores, plataformas 
e nuvem, aderindo totalmente aos principios de 
sustentabilidade de dados, design consciente da 
Estratégia Federal de Dados dos EUA e missao 4 
da estratégia nacional de dados do Reino Unido. 

O Delta fornece uma camada de governanga 

sobre o formato de dados do Parquet. Além disso, 
ele oferece muitas otimizagées de desempenho 
nao disponiveis no Parquet, prontas para uso. A 
abertura do formato de dados € uma consideragao 
critica. E o principal fator para impulsionar a 
geragao de habitos e a adogao das praticas e 

dos padrées recomendados. 
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Delta Sharing € um protocolo baseado em um conjunto enxuto de APIs REST 
para gerenciar o compartilhamento, as permiss6es e 0 acesso a qualquer ativo 
de dados armazenado nos formatos Delta ou Parquet. O protocolo define dois 
atores principais, o provedor de dados (fornecedor de dados, proprietario de 
dados) e o destinatario de dados (consumidor de dados). O destinatario, por 
defini¢ao, € independente do formato dos dados na origem. O Delta Sharing 
fornece as abstragées necess4rias para acesso controlado a dados em diversas 
linguagens e ferramentas. 


O Delta Sharing esta posicionado exclusivamente para responder a muitos dos 
desafios do compartilhamento de dados de maneira escalonavel dentro do 
contexto de dominios altamente regulamentados, como o setor publico: 


¢ Preocupacoes de privacidade e segurancga — Dados pessoais 
identificaveis ou dados de outra forma confidenciais ou restritos sao uma 
parte importante das necessidades de troca de dados de um governo 
orientado por dados e modernizado. Devido a natureza sensivel desses 
dados, é fundamental que a governanga do compartilhamento de dados seja 
mantida de forma coerente e unificada. Qualquer processo desnecessario 
e complexidade tecnolégica aumentam o risco de compartilhamento 
excessivo de dados. Com isso em mente, o Data Sharing foi projetado com 
praticas recomendadas de seguranga desde 0 inicio. O protocolo fornece 
criptografia de ponta a ponta, credenciais de curta duragao e recursos de 
auditoria e governanga acessiveis e intuitivos. Todos esses recursos estao 
disponiveis de forma centralizada em todas as suas tabelas Delta em todas 
as nuvens. 


Qualidade e precisao — Outro desafio do compartilhamento de dados é 
garantir que os dados compartilhados sejam de alta qualidade e precisao. 
Como os dados subjacentes sao armazenados como tabelas Delta, podemos 
garantir que a natureza transacional dos dados seja respeitada; o Delta 
garante as propriedades ACID dos dados. Além disso, o Delta oferece 
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suporte a restrigdes de dados para garantir os requisitos de qualidade dos 
dados no armazenamento. Infelizmente, outros formatos, como CSV, CSVW, 
ORC, Avro, XML etc., nado tém essas propriedades sem um esforc¢o adicional 
significativo. A questao se torna ainda mais relevante pelo fato de que a 
qualidade dos dados nao pode ser garantida da mesma forma no lado do 
provedor e do destinatario dos dados sem a reimplementagao exata dos 
sistemas de origem. E fundamental incorporar a qualidade e os metadados 
aos dados para garantir que a qualidade acompanhe os dados. Qualquer 
abordagem dissociada para gerenciar dados, metadados e qualidade 
separadamente aumenta 0 risco de compartilhamento e pode levar a 
resultados indesejaveis. 


Falta de padronizagao — Outro desafio do compartilhamento de dados 
é a falta de padronizagao em como os dados s&ao coletados, organizados 
e armazenados. Isso é particularmente pronunciado no contexto de 
atividades governamentais. Embora os governos tenham proposto 
formatos padrao (por exemplo, o Office for National Statistics promove 

o uso do CSVW), alinhar todas as empresas do setor publico e privado 
com Os padrées propostos por essas iniciativas € um grande desafio. 
Outros setores podem ter requisitos diferentes de escalabilidade, 
interoperabilidade, complexidade de formato, falta de estrutura em 
dados etc. A maioria dos padr6ées atualmente defendidos nao tem varios 
desses aspectos. O Delta é 0 candidato mais maduro para assumir a 
fungao central na padronizagao do formato de troca de dados. Ele foi 
criado como um formato de dados transacional e escalavel, aceita dados 
estruturados, semiestruturados e nao estruturados, armazena esquemas 
de dados e metadados junto com os dados e fornece um protocolo 

de compartilhamento escalonavel de nivel empresarial por meio do 

Delta Sharing. Por fim, o Delta € um dos projetos de cédigo aberto mais 
populares do ecossistema e, desde maio de 2022, ultrapassou 7 milhdes de 
downloads mensais. 
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¢ Barreiras culturais e organizacionais — Esses desafios podem ser * Desafios tecnicos — A Federagao em escala governamental ou ainda mais 
resumidos em uma palavra: atrito. Infelizmente, € um problema comum em varios setores e regides geograficas representa desafios técnicos. Cada 
para os funcionarios publicos lutarem para obter acesso a dados organizagao dentro dessa federagao tem sua plataforma e impulsiona 
internos e externos devido a processos complicados, politicas e padrées escolhas de tecnologia, arquitetura, plataforma e ferramentas. 
desatualizados. Os principios que estamos usando para construir nossas 
plataformas de dados e nossas plataformas de compartilhamento de Como podemos promover a interoperabilidade e troca de dados neste 
dados precisam ser autopromocionais, impulsionar a adogao e gerar vasto e diversificado ecossistema tecnolégico? Os dados sao 0 Unico 
habitos que sigam as praticas recomendadas. veiculo de integragao viavel. Desde que os formatos de dados que usamos 

sejam escalaveis, abertos e governados, podemos usa-los para abstrair de 

Se houver atrito com a adogao de padroes, a Unica maneira de garantir plataformas individuais e de suas complexidades intrinsecas. 
que os padroes sejam respeitados € por meio da aplicagao, 0 que, por si 
SO, € mais uma barreira para alcangar a sustentabilidade dos dados. As O formato Delta e 0 Delta Sharing resolvem essa grande variedade de requisitos 
organizagoes ja adotaram o Delta Sharing nos setores publico e privado. e desafios de maneira escalavel, robusta e aberta. Isso posiciona o Delta Sharing 
Por exemplo, 0 U.S. Citizenship and Immigration Services (USCIS) usa o como a escolha mais sélida para unificagéo e simplificagdo do protocolo e 
Delta Sharing para atender a varios requisitos de compartilhamento de mecanismo por meio do qual compartilhamos dados entre os setores pUblico 


dados entre agéncias. Da mesma forma, a Nasdaq descreve o Delta Sharing e privado. 
como o “futuro do compartilhamento de dados financeiros”, e esse futuro 


€ aberto e governado. 
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Data Sharing por meio de clean rooms de dados 


Levando um passo adiante as complexidades do compartilhamento de 


dados em um espa¢o altamente regulamentado e no setor publico, o que 


fazer se precisarmos compartilhar o conhecimento contido nos dados sem 


nunca conceder acesso direto aos dados de origem a partes externas? 


Esses requisitos podem acabar sendo viaveis e desejaveis quando o risco do 


compartilhamento de dados é muito baixo. 


Em muitos contextos do setor publico, ha uma preocupagaéo de que a 


combinagao dos dados que descrevem os cidadaos possa levar a um cenario 


de big brother, onde muitos dados sobre um individuo estao concentrados 


em um Unico ativo de dados. Se caisse nas maos erradas, tal ativo de dados 


hipotéticos poderia levar a consequéncias imensuraveis para os individuos e 


a confianga nos servicos do setor pUblico poderia desmoronar. Por outro lado, 


o valor de uma visao abrangente do cidadaéo poderia acelerar a tomada de 


decis6es importantes. Poderia melhorar imensamente a qualidade das politicas 


e dos servigos prestados aos cidadaos. 


Collaborator 1 A 


Delta Sharing 


Mutually approved 
jobs on trusted 


Existing data tables compute 
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A Collaborator 2 


Delta Sharing 


Existing data tables 
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As clean rooms de dados atendem a essa necessidade especifica. Com clean 
rooms de dados, vocé pode compartilhar dados com terceiros em um ambiente 
com privacidade segura. Com o Unity Catalog, vocé pode ativar controles de 
acesso refinados aos dados e atender aos seus requisitos de privacidade. Nessa 
arquitetura, os participantes dos dados nunca tém acesso aos dados brutos. As 
Unicas saidas das clean rooms sao os ativos de dados gerados de forma pré- 
acordada, governada e totalmente controlada que garante a conformidade com 
Os requisitos de todas as partes envolvidas. 


Por fim, as clean rooms de dados e 0 Delta Sharing podem atender a implantagées 
hibridas on-premises e externamente, em que os dados com acesso mais restrito 
permanecem no local. Por outro lado, dados menos restritos sao gratuitos para 
aproveitar o poder das ofertas de nuvem. Nesse cenario, pode haver a necessidade 
de combinar 0 poder da nuvem com os dados restritos para resolver casos de uso 
avangados em que os recursos nao estao disponiveis nas plataformas de dados 
locais. As clean rooms de dados podem garantir que nenhuma copia fisica dos 
dados brutos restritos seja criada, que os resultados sejam produzidos dentro do 
ambiente controlado da clean room e que os resultados sejam compartilhados 
com o ambiente local (se os resultados mantiverem o acesso restrito dentro das 
politicas definidas) ou sejam encaminhados para qualquer outro sistema de destino 
compativel e predeterminado. 
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Valor do compartilhamento de dados do cidadao 


Cada decisao tomada pelo governo € uma decisao que afeta seus cidadaos. Seja 
uma mudanga de politica, concessao de um beneficio ou prevengao do crime, a 
decisao pode influenciar significativamente a qualidade da nossa sociedade. Os 
dados sao um fator crucial para tomar as decis6es certas e justificar as decisdes 
tomadas. Simplificando, ndo podemos esperar decisées de alta qualidade 

sem a alta qualidade dos dados e uma visao completa dos dados (dentro do 
contexto permitido). Sem o compartilhamento de dados, permaneceremos em 
uma posicgao altamente fragmentada, na qual nossa capacidade de tomar essas 
decisées é severamente limitada ou mesmo completamente comprometida. 
Neste blog, abordamos varias solugées tecnolégicas disponiveis no lakehouse 
que podem reduzir os riscos e acelerar a forma como 0 governo aproveita o 
ecossistema de dados de forma sustentavel e escalavel. 


Para mais detalhes sobre os casos de uso do setor que o Delta Sharing esta 


abordando, consulte o e-book Uma nova abordagem ao compartilhamento 
de dados. 


Comece a experimentar com estes 
notebooks gratuitos da Databricks. 
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SECAO 


Notebooks e conjuntos de dados 
prontos para uso 
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Esta segao inclui varios aceleradores de solugées — exemplos gratuitos 


e prontos para uso de solugées de dados de diferentes setores, desde 


varejo até manufatura e saude. Cada um dos seguintes cenarios inclui 


notebooks com codigo e instrug6es passo a passo para ajudar vocé a 


comegar. Obtenha experiéncia pratica com a Plataforma Databricks 


Lakehouse testando o seguinte: 
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Eficacia geral do equipamento 


Ingira dados de sensores de 
equipamentos para geragao 

de métricas e tomada de decisao 
baseada em dados 


> Explore a solugao >) 


Analise do ponto de venda 
em tempo real 


Calcule os estoques atuais de varios 
produtos em diversas lojas com 
o Delta Live Tables 


> Exploreasolugao © 
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Gémeos digitais 

Aproveite os gémeos digitais — 
representag6ées virtuais de dispositivos 
e objetos — para otimizar as operagdes 
e obter insights 


> Exploreasolugao © 


Mecanismos de recomendagao 
para personalizagao 


Melhore a experiéncia do usuario 
e aconversao dos clientes com 
recomendacoes personalizadas 


> Exploreasolugao © 


Compreender os dados 
de transparéncia de precos 


Ingira com eficiéncia grandes conjuntos 
de dados de satide para criar 
transparéncia de precos e entender 
melhor os custos de assisténcia médica 


> Exploreasolugao © 


Aceleradores de solugées adicionais com notebooks prontos para uso podem ser 


encontrados aqui: 


Aceleradores de solugées da Databricks @ 


SECAO 


databricks 


Estudos de caso 


4.1. Akamai 

4.2 Grammarly 

4.3 Honeywell 

4.4 Wood Mackenzie 
4.5 Rivian 

4.6 AT&T 
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SETOR 
Tecnologia e software 


SOLUGAO 
Detecgao de ameagas 


CASO DE USO DA PLATAFORMA 


Delta lake, Streaming de dados, Photon, 


Databricks SQL 


NUVEM 
Azure 
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SEGAO 4.1 
Akamai oferece analise de seguranga 
em tempo real usando o Delta Lake 


<1 <85% 
Tempo minimo de ingestao, Das queries tem tempo de resposta 
reduzido de 15 minutos de 7 segundos ou menos 


A Akamai administra uma rede de distribuig&éo de conteddo (CDN) difundida e altamente 
distribuida. Sua CDN usa aproximadamente 345.000 servidores em mais de 135 paises e 
mais de 1.300 redes em todo o mundo para rotear o trafego da internet para algumas das 
maiores empresas de midia, comércio, finangas, varejo e muitos outros setores. Cerca de 
30% do trafego da internet flui pelos servidores da Akamai. A Akamai também oferece 
solugées de seguranga na nuvem. 


Em 2018, a empresa langou uma ferramenta de analise de seguranga na web que oferece 
aos clientes da Akamai uma interface Unica e unificada para avaliar uma grande variedade 
de eventos de seguranga de streaming e analisar esses eventos. A ferramenta de analise 
da web ajuda os clientes da Akamai a tomar medidas informadas em relagao a eventos de 
segurancga em tempo real. A Akamai consegue transmitir grandes quantidades de dados 

e atender aos SLAs rigorosos que fornece aos clientes, aproveitando o Delta Lake ea 
Plataforma Databricks Lakehouse para a ferramenta de analise da web. 
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Ingestao e streaming de enormes quantidades de dados Depois de realizar provas de conceito com varias empresas, a Akamai optou 


A ferramenta de analise de seguranga na web da Akamai ingere 
aproximadamente 10 GB de dados relacionados a eventos de seguranga por 
segundo. O volume de dados pode aumentar significativamente quando os 
clientes de varejo realizam um grande numero de vendas — ou em grandes dias 
de compras, como Black Friday ou Cyber Monday. A ferramenta de analise de 
seguranga da web armazena varios petabytes de dados para fins de anlise. 
Essas analises sao realizadas para proteger os clientes da Akamai e fornecer a 
capacidade de explorar e consultar eventos de seguranga por conta prépria. 


A ferramenta de analise de seguranga na web inicialmente contou com 

uma arquitetura local que executa o Apache Spark™ no Hadoop. A Akamai 
oferece contratos rigorosos de nivel de servigo (SLAs) a seus clientes de 5 

a 7 minutos a partir do momento em que ocorre um ataque até que ele seja 
exibido na ferramenta. A empresa buscou melhorar a velocidade de ingestao e 
consulta para atender a esses SLAs. “Os dados precisam ser 0 mais em tempo 
real possivel para que os clientes possam ver o que os esta atacando”, diz 
Tomer Patel, gerente de engenharia da Akamai. “Fornecer rapidamente dados 
consultaveis aos clientes é fundamental. Queriamos nos afastar do on-prem 
para melhorar o desempenho e nossos SLAs para que a laténcia fosse de 
segundos em vez de minutos.” 


O Delta Lake nos permite nao so consultar melhor os dados, 
mas também adquirir um aumento no volume de dados. Vimos 
um aumento de 80% no trafego e nos dados no ultimo ano, 


portanto, ser capaz de expandir rapidamente é fundamental. 


Tomer Patel 
Gerente de engenharia, Akamai 
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por basear sua arquitetura de analise de streaming no Spark e na Plataforma 
Databricks Lakehouse. “Devido a nossa escala e as demandas de nosso SLA, 
determinamos que a Databricks era a solugao certa para nés”, diz Patel. “Quando 
consideramos a otimizagao do armazenamento e 0 armazenamento em cache 
de dados, se f6ssemos com outra solugao, nao conseguiriamos alcangar o 
mesmo nivel de desempenho’”. 


Melhora da velocidade e redugao de custos 


Hoje, a ferramenta de analise de seguranga da web ingere e transforma dados, 
armazena-os no armazenamento em nuvem e envia a localizagao do arquivo via 
Kafka. Em seguida, ela usa um job do Databricks como 0 aplicativo de ingestao. 

O Delta Lake, que é o formato de armazenamento de cédigo aberto na base da 
Plataforma Databricks Lakehouse, aceita queries em tempo real sobre os dados 
de analise de seguranga da web. O Delta Lake também permite que a Akamai 
cresga rapidamente. “O Delta Lake nos permite nao sé consultar melhor os dados, 
mas também adquirir um aumento no volume de dados”, diz Patel. “Vimos um 
aumento de 80% no trafego e nos dados no Ultimo ano, portanto, ser capaz de 
expandir rapidamente é fundamental.” 


A Akamai também usa o Databricks SQL (DBSQL) e Photon, que fornecem 
desempenho de query extremamente rapido. Patel acrescentou que a Photon 
proporcionou um impulso significativo para o desempenho das queries. Em 
geral, a arquitetura de streaming da Databricks combinada com DBSQL e 
Photon permite a Akamai alcangar analises em tempo real, o que se traduz em 
beneficios de negécios em tempo real. 
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Patel gosta que o Delta Lake seja de cddigo aberto, pois a empresa se 
beneficiou de uma comunidade de usuarios trabalhando para melhorar o 
produto. “O fato de que o Delta Lake é de cédigo aberto e ha uma grande 
comunidade por tras dele significa que nao precisamos implementar tudo por 
conta prépria”, diz Patel. “N6s nos beneficiamos de bugs corrigidos que outros 
encontraram e de otimizagdes que sao contribuidas para o projeto”. A Akamai 
trabalhou em conjunto com a Databricks para garantir que o Delta Lake pudesse 
atender aos requisitos de escala e desempenho definidos pela empresa. Essas 
melhorias voltaram para o projeto (muitas das quais foram disponibilizadas 
como parte do Delta Lake 2.0). Assim, qualquer usuario que executar o Delta 
Lake agora se beneficia da tecnologia sendo testada em grande escala em um 
cenario de produgao do mundo real. 
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Atender a requisitos agressivos de escala, confiabilidade 
e desempenho 


O uso do Spark Structured Streaming na Plataforma Databricks Lakehouse 
permite que a ferramenta de analise de seguranga na web transmita grandes 
volumes de dados e fornega analises em tempo real e de baixa laténcia como 
servico aos clientes da Akamai. Dessa forma, a Akamai consegue disponibilizar 
dados de eventos de seguranga aos clientes dentro do SLA de 5 a7 minutos 

a partir do momento em que ocorre um ataque. “Nosso foco é desempenho, 
desempenho e desempenho”, reforga Patel. “O desempenho e a escalabilidade 
da plataforma sao 0 que nos motiva.” 


Usando a Plataforma Databricks Lakehouse, agora leva menos de 1 minuto 
para ingerir os dados do evento de seguranga. “Reduzir o tempo de ingestao 
de 15 minutos para menos de 1 minuto 6 uma enorme melhoria”, diz Patel. 
“Isso beneficia nossos clientes porque eles podem ver os dados do evento 
de seguranga mais rapidamente e tém uma visdo precisa do que esta 
acontecendo, bem como a capacidade de filtrar tudo isso.” 


A maior prioridade da Akamai é proporcionar aos clientes uma boa experiéncia 
e tempos de resposta rapidos. Até o momento, a Akamai transferiu cerca 

de 70% dos dados de eventos de seguranga de sua arquitetura local para o 
Databricks, e o SLA para o tempo de query e resposta do cliente melhorou 
significativamente como resultado. “Agora, com a mudanga para o Databricks, 
nossos clientes tém um tempo de resposta muito melhor, e mais de 85% das 
queries sao concluidas em menos de 7 segundos.” Fornecer esse tipo de dados 
em tempo real significa que a Akamai pode ajudar seus clientes a se manterem 
vigilantes e manter uma configuragaéo de seguranga ideal. 
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SETOR 
Tecnologia e software 


SOLUGAO 
Mecanismos de recomendagao, eficacia 
da publicidade, valor da vida Util do cliente 


CASO DE USO DA PLATAFORMA 
Lakehouse, Delta Lake, Unity Catalog, 
machine learning, ETL 
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SEGAO 4.2 
Grammarly usa o Databricks Lakehouse 
para melhorar a experiéncia do usuario 


110% 5 bilhdoes 


Queries mais rapidas do que um data 
warehouse a 10% do custo de ingestao 


Eventos diarios disponiveis para 
analise em menos de 15 minutos 


A missao da Grammarly é melhorar a vida melhorando a comunicagao. A assisténcia 

de comunicagao confiavel baseada em IA da empresa fornece sugest6es em tempo 

real para ajudar individuos e equipes a escrever com mais confianga e atingir melhores 
resultados. Suas ofertas abrangentes — Grammarly Premium, Grammarly Business, 
Grammarly for Education e Grammarly for Developers — fornecem suporte de 
comunicagao lider onde quer que a escrita acontega. A medida que a empresa cresceu 
ao longo dos anos, seu sistema de analise legado e desenvolvido internamente dificultou 


a avaliagao de grandes conjuntos de dados de forma rapida e econémica. 


Ao migrar para a Plataforma Databricks Lakehouse, a Grammarly agora pode manter 
uma plataforma de analise flexivel, dimensionavel e altamente segura que ajuda 
30 milhées de pessoas e 50.000 equipes em todo 0 mundo a escrever com mais 


eficiéncia todos os dias. 
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Aproveitar os dados para melhorar as comunicagoes 
para milhées de usuarios e milhares de equipes 


Quando as pessoas usam a assisténcia de comunicagao de IA da Grammarly, 
elas recebem sugest6es que ajudam a melhorar varios aspectos de 
comunicagao, incluindo ortografia e corregao de gramatica, clareza e concisao, 
escolha de palavras, estilo e tom. A Grammarly recebe feedback quando os 
usuarios aceitam, rejeitam ou ignoram suas sugesté6es por meio de eventos 
criados pelo aplicativo, que totalizam cerca de 5 bilhées de eventos por dia. 


Historicamente, a Grammarly dependia de uma plataforma de analise legada 
interna e usava uma linguagem interna semelhante a SQL que consumia muito 
tempo para aprender e dificultava integrar novos contratados. A medida que 
a empresa crescia, os analistas de dados da Grammarly descobriram que a 
plataforma nao atendia suficientemente as necessidades de suas fungdes 


essenciais de negocios, principalmente marketing, vendas e sucesso do cliente. 


Os analistas tinnham que copiar e colar dados de planilhas porque o sistema 
existente nao conseguia ingerir efetivamente os dados externos necessarios 
para responder a perguntas como “Qual canal de marketing oferece o maior 
ROI?”. Era um desafio gerar relatérios porque o sistema existente nao oferecia 
suporte aos painéis do Tableau e os lideres e analistas da empresa precisavam 
garantir que pudessem tomar decis6es com rapidez e confianga. 
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O Databricks Lakehouse nos deu a flexibilidade de liberar 
nossos dados sem comprometer. Essa flexibilidade nos permitiu 
acelerar a analise a um ritmo que nunca alcangamos antes. 


Chris Locklin 
gerente de engenharia de plataformas de dados da Grammarly 


A Grammarly também buscou unificar seus data warehouses para dimensionar 
e melhorar os recursos de armazenamento e consulta de dados. Do jeito 

que estava, grandes clusters do Amazon EMR funcionavam 24 horas por dia 

e aumentavam os custos. Com as varias fontes de dados, a equipe também 
precisava manter o controle de acesso. “O controle de acesso em um sistema 
de arquivos distribuido é dificil, e s6 fica mais complicado a medida que vocé 
ingere mais fontes de dados”, diz Chris Locklin, gerente de engenharia de 
plataformas de dados da Grammarly. Entretanto, a confianga em um Unico fluxo 
de trabalho de streaming dificultou a colaboragao entre as equipes. Os silos 

de dados surgiram a medida que diferentes areas de negécios implementaram 
ferramentas de analise individualmente. “Cada equipe decidiu resolver suas 
necessidades de analise da maneira que achava melhor”, diz Locklin. “Isso criou 
desafios de consisténcia e para saber qual conjunto de dados estava correto.” 
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A medida que a estratégia de dados evoluia, a prioridade da Grammarly era 
aproveitar ao maximo os dados analiticos e, ao mesmo tempo, manté-los seguros. 
Isso foi crucial porque a seguranga é a prioridade numero um e€ 0 recurso mais 
importante da Grammarly, tanto na forma como protege os dados de seus 
usuarios quanto na forma como garante que os dados da prépria empresa 
permanegcam seguros. Para isso, a equipe de plataforma de dados da Grammarly 
buscou consolidar dados e unificar a empresa em uma Unica plataforma. Isso 
significava manter uma infraestrutura altamente segura que pudesse acompanhar 
oO crescimento da empresa, melhorando a flexibilidade de ingestao, reduzindo os 
custos e estimulando a colaboragao. 


Melhorar a analise, a visualizagao e a tomada de decisées 
com o lakehouse 


Depois de realizar varias provas de conceito para aprimorar a infraestrutura, a 
Grammarly migrou para a Plataforma Databricks Lakehouse. Colocar todos os 
dados analiticos no lakehouse criou um hub central para todos os produtores 
de dados e consumidores em todo 0 Grammarly, com o Delta Lake no nucleo. 


Usando a arquitetura de lakehouse, os analistas de dados da Grammarly agora 
tém uma interface consolidada para andalises, o que leva a uma Unica fonte de 
verdade e confianga na precisao e disponibilidade de todos os dados gerenciados 
pela equipe da plataforma de dados. Em toda a organizagao, as equipes estao 
usando o Databricks SQL para realizar queries dentro da plataforma em dados de 
produtos gerados internamente e dados externos de parceiros de plataformas 

de publicidade digital. Agora, eles podem se conectar facilmente ao Tableau e 
criar dashboards e visualizag6es para apresentar aos executivos e as principais 
partes interessadas. 
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“A seguranga é de extrema importancia na Grammarly, e 0 objetivo numero um 
da equipe é possuir e proteger nossos dados analiticos”, diz Locklin. “Outras 
empresas pedem seus dados, armazenam-nos e permitem que vocé faga 
analises neles. Da mesma forma que a Grammarly garante que os dados dos 
usuarios permanegam sempre deles, queriamos garantir que os dados de 
nossa empresa permanecessem nossos. Os dados da Grammarly permanecem 
dentro da Grammarly”. 


Com os dados consolidados no lakehouse, diferentes areas de negoécios da 
Grammarly agora podem analisar dados de forma mais completa e eficaz. Por 
exemplo, a equipe de marketing da Grammarly usa publicidade para atrair novos 
negocios. Usando o Databricks, a equipe pode consolidar dados de varias fontes 
para extrapolar o valor da vida util de um usuario, compara-lo com os custos de 
aquisigao de clientes e obter feedback rapido sobre as campanhas. Em outros 
lugares, os dados capturados das interagdes do usuario fluem para um conjunto 
de tabelas usadas por analistas para analise ad hoc para informar e melhorar a 
experiéncia do usuario. 


Ao consolidar dados em uma plataforma unificada, a Grammarly eliminou silos de 
dados. “A capacidade de trazer todos esses recursos, processamento de dados 
e analise sob a mesma plataforma usando o Databricks é extremamente valiosa”, 
diz Sergey Blanket, diretor de inteligéncia de negécios da Grammarly. “Fazer tudo, 
desde ETL e engenharia até analise e ML sob 0o mesmo guarda-chuva, remove 
barreiras e facilita o trabalho de todos com os dados e uns com os outros.” 
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Para gerenciar o controle de acesso, permitir a observabilidade de ponta a 
ponta e monitorar a qualidade dos dados, a Grammarly conta com os recursos 
de linhagem de dados no Catalogo Unity. “A linhagem de dados nos permite 
monitorar efetivamente o uso de nossos dados e garantir que eles mantenham 
os padrées definidos como uma equipe de plataforma de dados”, diz Locklin. “A 
linhagem é a ultima pega crucial para o controle de acesso. Ela permite que os 
analistas aproveitem os dados para realizar suas tarefas e, ao mesmo tempo, 
aderir a todos os padroes de uso e controles de acesso, mesmo ao recriar 
tabelas e conjuntos de dados em outro ambiente.” 


O tempo mais rapido para obter insights gera decisdes de 
negocios mais inteligentes 


Usando a Plataforma Databricks Lakehouse, as equipes de engenharia da 
Grammarly agora tem uma plataforma centralizada e personalizada e uma fonte 
de dados consistente em toda a empresa, resultando em maior velocidade e 
eficiéncia e custos reduzidos. A arquitetura de lakehouse levou a queries 110% 
mais rapidas, a 10% do custo para ingerir em relagao a um data warehouse. 
Agora, a Grammarly pode disponibilizar 5 bilhées de eventos diarios para analise 
em menos de 15 minutos, em vez de 4 horas, permitindo agregar dados de baixa 
laténcia e otimizagao de queries. Isso permite que a equipe receba rapidamente 
feedback sobre os novos recursos que estao sendo implantados e entenda se 
estao sendo adotados conforme o esperado. Em Ultima analise, isso os ajuda 

a entender como os grupos de usuarios interagem com a UX, melhorando a 
experiéncia e garantindo que os recursos e as versdes de produtos agreguem 
mais valor aos usuarios. “Tudo 0 que minha equipe faz € se concentrar em 

criar uma experiéncia rica e personalizada que capacite as pessoas a se 
comunicarem de forma mais eficaz e alcangarem seu potencial”, diz Locklin. 
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Mudar para a arquitetura de lakehouse também solucionou o desafio do 
controle de acesso sobre os sistemas de arquivos distribuidos, enquanto o 
Unity Catalog habilitou controles de acesso refinados baseados em fungao 

e linhagem de dados em tempo real. “O Unity Catalog nos permite gerenciar 
permiss6es de arquivos com mais flexibilidade do que seria possivel com um 
banco de dados"”, afirma Locklin. “Ele solucionou um problema que minha equipe 
nao poderia resolver em escala. Enquanto o uso do Databricks nos permite 
manter dados analiticos internos, o Unity Catalog nos ajuda a continuar a 
manter os mais altos padroes de protecao de dados, controlando paradigmas 
de acesso dentro dos nossos dados. Isso abre um mundo totalmente novo de 
coisas que podemos fazer.” 


Em ultima analise, migrar para a Plataforma Databricks Lakehouse ajudou 

a Grammarly a promover uma cultura orientada por dados, em que os 
funcionarios obtém acesso rapido a analises sem a necessidade de escrever 
queries complexas, sempre mantendo as praticas de seguranga de nivel 
empresarial da Grammarly. “A missao da nossa equipe é ajudar a Grammarly 
a tomar decisées de negécios melhores e mais rapidas”, acrescenta Blanket. 
“Minha equipe nao seria capaz de executar efetivamente essa missado se nao 
tivessemos uma plataforma como a Databricks disponivel para nés.” Talvez 

oO mais importante seja que a migragao de uma rigida infraestrutura legada 
da a Grammarly a capacidade de adaptacao para fazer mais, sabendo que a 
plataforma evoluira a medida que suas necessidades evoluem. “O Databricks 
nos deu a flexibilidade de liberar nossos dados sem comprometer”, diz Locklin. 
“Essa flexibilidade nos permitiu acelerar a analise a um ritmo que nunca 
alcangamos antes.” 
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SECAO 4.3 
Honeywell seleciona o Delta Live Tables 
para streaming de dados 


As empresas estao sob crescente pressd4o para reduzir 0 uso de energia e, aa mesmo 
tempo, querem reduzir os custos e aumentar a eficiéncia. A Honeywell fornece solugées 
especificas do setor que incluem produtos e servigos aeroespaciais, tecnologias de 
controle para edificios e industrias e materiais de desempenho em todo o mundo. A 
diviséo de Solugées Ambientais e de Energia da Honeywell usa sensores de loT e outras 
tecnologias para ajudar as empresas em todo o mundo a gerenciar a demanda de 
energia, reduzir o consumo de energia e as emiss6es de carbono, otimizar a qualidade 
do ar interno e melhorar o bem-estar dos ocupantes. 


Para isso, a Honeywell precisa coletar grandes quantidades de dados. Usando o Delta Live 
Tables na Plataforma Databricks Lakehouse, a equipe de dados da Honeywell agora pode 
ingerir bilhées de linhas de dados de sensores no Delta Lake e criar automaticamente 
endpoints SQL para queries em tempo real e insights de varias camadas sobre os dados 


em escala. Isso ajuda a Honeywell a melhorar a forma como gerenciam os dados e extraem 


mais valor deles, tanto para eles prdéprios quanto para seus clientes. 


O Databricks nos ajuda a reunir muitas fontes de dados diferentes, fazer 
agregacoes e controlar a quantidade significativa de dados que coletamos 
de nossos edificios para podermos oferecer valor aos clientes. 


Dr. Chris Inkpen 
arquiteto de solugées globais, Solugdes Ambientais e de Energia da Honeywell 
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Processamento de bilhdées de pontos de dados de loT por dia 


As solugées e os servigos da Honeywell séo usados em milhdes de edificios em 
todo o mundo. Ajudar seus clientes a criar edificios seguros, mais sustentaveis 
e produtivos pode exigir milhares de sensores por edificio. Esses sensores 
monitoram os principais fatores, como temperatura, pressao, umidade e 
qualidade do ar. Além dos dados coletados pelos sensores dentro de um prédio, 
os dados também s&o coletados da area externa, como dados climaticos e de 
poluigao. Outro conjunto de dados consiste em informagées sobre os prdprios 
edificios, como tipo de construgao, propriedade, planta baixa, metragem 
quadrada de cada andar e metragem quadrada de cada quarto. Esse conjunto 
de dados € combinado com os dois fluxos de dados diferentes, somando 
muitos dados em varios formatos estruturados e nao estruturados, incluindo 
imagens e fluxos de video, dados de telemetria, dados de eventos etc. Em dias 
de pico, a Honeywell ingere entre 200 a 1.000 eventos por segundo em qualquer 
edificio, o que equivale a bilhOes de pontos de dados por dia. A infraestrutura 
de dados existente da Honeywell foi desafiada a atender a essa demanda. Isso 
também dificultou para a equipe de dados da Honeywell consultar e visualizar 
seus dados dispares para que pudesse fornecer aos clientes informagées e 
analises rapidas e de alta qualidade. 


ETL simplificado: pipelines de dados reutilizaveis 
e de alta qualidade 


Com as tabelas do Delta Live Tables (DLT) na Plataforma Databricks Lakehouse, a 
equipe de dados da Honeywell agora pode ingerir bilhées de linhas de dados de 
sensores no Delta Lake e criar automaticamente endpoints SQL para queries em 
tempo real e insights multicamadas de dados em escala. “Nao precisamos fazer 
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nada para escalonar o DLT”, diz Chris Inkpen, arquiteto de solugées globais das 
Solugdes Ambientais e de Energia da Honeywell. “Mesmo quando fornecemos 
mais dados ao sistema, ele da conta. Desde 0 inicio, tivemos a confianga de que 
o sistema poderia lidar com todos os tipos de dados inseridos.” 


A Honeywell credita a Plataforma Databricks Lakehouse por ajuda-la a unificar 
seus vastos e variados dados — em batch, streaming, estruturados e nao 
estruturados — em uma Unica plataforma. “Temos muitos tipos de dados 
diferentes. A Plataforma Databricks Lakehouse nos permite usar programas 
como Apache Kafka e Auto Loader para carregar e processar varios tipos 

de dados e tratar tudo como um fluxo de dados, 0 que é incrivel. Depois de 
obtermos dados estruturados a partir de dados nao estruturados, podemos 
escrever pipelines padronizados.” 


Os engenheiros de dados da Honeywell agora podem criar e aproveitar seus 
prdprios pipelines ETL com o Delta Live Tables e obter insights e analises 
rapidamente. Os pipelines ETL podem ser reutilizados, independentemente 
do ambiente, e os dados podem ser executados em batches ou streams. Isso 
também ajudou a equipe de dados da Honeywell a fazer a transig¢ao de uma 
equipe pequena para outra maior. “Quando escreviamos nossos primeiros 
pipelines antes do DLT, somente uma pessoa poderia trabalhar em uma parte 
da funcionalidade. Agora que temos o DLT e a capacidade de ter pastas com 
funcionalidade comum, temos uma plataforma muito boa onde podemos 
facilmente girar pipelines diferentes.” 


O DLT também ajudou a Honeywell a estabelecer arquivos de log padrao para 
monitorar e justificar os custos de seus pipelines de produtos. “Utilizando o DLT, 
podemos analisar quais partes do nosso pipeline precisam de otimizagao”, diz 
Inkpen. “Com os pipelines padrao, isso era muito mais cadtico.” 
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Facilidade, simplicidade e escalabilidade em toda 
a infraestrutura 


O Delta Live Tables ajudou a equipe de dados da Honeywell a consultar 
consistentemente dados complexos, oferecendo simplicidade de escala. Ele 
também permite visualizar dados de ponta a ponta dos streams de dados da 
Honeywell a medida que fluem para sua infraestrutura, sao transformados e, em 
seguida, fluem para fora. “Noventa por cento do nosso ETL agora é capturado 
em diagramas, e isso € uma ajuda consideravel e melhora a governanga de 
dados. O DLT incentiva — e quase impée — um bom design”, diz Inkpen. 


Usar o lakehouse como um workspace compartilhado ajudou a promover o 
trabalho em equipe e a colaboragao na Honeywell. “A equipe colabora muito 
bem agora, trabalhando juntos todos os dias para dividir 0 pipeline em suas 
prdprias hist6érias e cargas de trabalho”, conta Inkpen. 


Entretanto, a capacidade de gerenciar dados de streaming com baixa laténcia 

e melhor throughput aprimorou a precisao e reduziu os custos. “Uma vez que 
projetamos algo usando o DLT, estamos muito seguros contra problemas de 
escalabilidade — certamente cem vezes melhor do que se nao tivéssemos 
escrito no DLT", explica Inkpen. “Podemos entao voltar e ver como deixar um job 
tradicional mais eficiente e menos dispendioso. Estamos em uma posigao muito 
melhor para tentar fazer isso a partir do DLT.” 
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O uso do Databricks e do DLT também ajuda a equipe da Honeywell a atuar com 
maior agilidade, o que permite inovar mais rapidamente e, ao mesmo tempo, 
capacitar os desenvolvedores a responder aos requisitos dos usuarios quase 
imediatamente. “Nossa arquitetura anterior tornava impossivel saber quais eram 
nossos gargalos e 0 que precisavamos para escalar. Agora podemos fazer data 
science quase em tempo real.” 


Em ultima analise, a Honeywell agora pode fornecer aos clientes os dados e 

a analise necessarios para tornar seus edificios mais eficientes, saudaveis e 
seguros para os ocupantes. “Estou sempre procurando maneiras de melhorar 
nossos ciclos de vida, o tempo de langamento no mercado e a qualidade dos 
dados”, diz Inkpen. “O Databricks nos ajuda a reunir muitas fontes de dados 
diferentes, fazer agregag6es e controlar a quantidade significativa de dados 
que coletamos de nossos edificios para podermos oferecer valor aos clientes.” 


Pronto para comegar? Saiba mais sobre o Delta Live Tables aqui. 
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SEGAO 4.4 
Wood Mackenzie ajuda os clientes na transigao 
para um futuro mais sustentavel 


12 bilhé6es 80-90% Economia de custos 
Pontos de dados processados Redugao notempo Nas operagoes por meio da 
a cada semana de processamento automacao do fluxo de trabalho 


A Wood Mackenzie oferece consultoria e analise personalizadas para uma ampla 
gama de clientes nos setores de energia e recursos naturais. Fundada em Edimburgo, 
a primeira empresa cultivou profunda experiéncia em petrdleo e gas upstream e, 

em seguida, ampliou seu foco para fornecer uma visdo detalhada de cada setor 


interconectado dos setores de energia, produtos quimicos, metais e mineragao. 


Hoje, ela se vé desempenhando um papel importante na transigao para um futuro 
mais sustentavel. Usar o Databricks Workflows para automatizar pipelines ETL ajuda 
a Wood Mackenzie a ingerir e processar grandes quantidades de dados. O uso de 
um fluxo de trabalho comum proporciona maior visibilidade aos membros da equipe 
de engenharia, incentivando uma melhor colaboragao. Com um fluxo de trabalho 
automatizado e transparente, a equipe teve um aumento na produtividade e na 


qualidade dos dados e um caminho mais facil para corrigir problemas de pipeline. 
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Fornecendo insights para o setor de energia 


Atendendo a missao da Wood Mackenzie, o produto Lens € uma plataforma 

de analise de dados criada para fornecer insights nos principais pontos de 
decisao para os clientes no setor de energia. Alimentando o Lens estado grandes 
quantidades de dados coletados de varias fontes de dados e sensores usados 
para monitorar a criagao de energia, produgao de petréleo e gas e muito mais. 
Essas fontes de dados atualizam cerca de 12 bilhées de pontos de dados 

toda semana, que devem ser ingeridos, limpos e processados como parte da 
entrada para a plataforma Lens. Yanyan Wu, vice-presidente de dados da Wood 
Mackenzie, gerencia uma equipe de profissionais de big data que constroem 

e mantém o pipeline ETL que fornece dados de entrada para o Lens. A equipe 
esta usando a Plataforma Databricks Lakehouse e o Apache Spark™ para 
processamento paralelo, o que proporciona maiores beneficios de desempenho 
e escalabilidade em comparagao com um sistema de no Unico anterior que 
opera sequencialmente. “Vimos uma redugaéo de 80 a 90% no tempo de 
processamento de dados, 0 que resulta em dados mais atualizados, mais 
completos e mais precisos para os nossos clientes”, diz Wu. 


Nossa miss4@o é transformar a forma como alimentamos o planeta. 
Nossos clientes do setor de energia precisam de dados, consultoria 
e pesquisas para alcangar essa transformagao. O Databricks 
Workflows nos da a velocidade e a flexibilidade para fornecer 


os insights de que nossos clientes precisam. 


Yanyan Wu 
vice-presidente de dados, Wood Mackenzie 
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Maior colaboracgao e transparéncia com um fluxo 
de trabalho comum 


O pipeline de dados gerenciado pela equipe inclui varios estagios para padronizar 
e limpar dados brutos, que podem ser estruturados ou nao estruturados e podem 
estar na forma de PDFs ou mesmo de anotagdes manuscritas. 


Diferentes integrantes da equipe de dados sao responsaveis por diferentes 
partes do pipeline, e ha uma dependéncia entre os estagios de processamento 
de cada integrante. Usando o Databricks Workflows, a equipe definiu um fluxo 
de trabalho comum usado por todos os integrantes. Cada estagio do pipeline é 
implementado em um notebook Python, que é executado como um job no fluxo 
de trabalho principal. 


Agora, cada membro da equipe pode ver exatamente qual cédigo esta sendo 
executado em cada estagio, facilitando a identificagado da causa do problema. 
Saber quem € 0 proprietario da parte do pipeline que originou 0 problema 
torna a corregao de problemas muito mais rapida. “Sem um fluxo de trabalho 
comum, diferentes membros da equipe executavam seus notebooks de forma 
independente, sem saber que a falha na sua execugao afetava os estagios 
posteriores”, explica Meng Zhang, analista de dados principal da Wood 
Mackenzie. “Ao tentar executar novamente os notebooks, era dificil saber qual 
versao foi executada inicialmente e a versdo mais recente a ser usada.” 
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Usar os recursos de alerta do Workflows para notificar a equipe quando ha falha 
em uma tarefa de fluxo de trabalho garante que todos saibam que ocorreu a 
falha e permite que a equipe trabalhe em conjunto para resolver o problema 
rapidamente. A definigao de um fluxo de trabalho comum criou consisténcia e 
transparéncia, o que facilitou a colaboragao. “Usar o Databricks Workflows nos 
permitiu incentivar a colaboragao e romper as paredes entre diferentes estagios 
do processo”, explica Wu. “Permitiu que todos nés falassemos a mesma lingua.” 


Criar transparéncia e consisténcia nao foi a Unica vantagem percebida pela 
equipe. O uso do Workflows para automatizar a execugao de notebooks também 
levou a uma economia de custos em comparagao com a execugao manual de 
notebooks interativos. 


Melhor produtividade no desenvolvimento de cédigo 


O processo de desenvolvimento do pipeline de ETL da equipe envolve a 
iteragao em notebooks PySpark.A utilizagao de notebooks interativos na IU do 
Databricks facilita o desenvolvimento e o teste manual de um notebook para 

os profissionais de dados da equipe. Como o Databricks Workflows permite a 
execugao de notebooks como tipo de tarefa (juntamente com arquivos Python, 
arquivos JAR e outros tipos), quando 0 cédigo esta pronto para produgao, é facil 
e econdmico automatiza-lo, adicionando-o a um fluxo de trabalho. O fluxo de 
trabalho pode ser facilmente revisado, adicionando ou removendo quaisquer 
etapas do fluxo definido. Essa maneira de trabalhar mantém o beneficio do 
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desenvolvimento manual de notebooks com a interface interativa do notebook 
e€, ao mesmo tempo, aproveita o poder da automagao, 0 que reduz os possiveis 
problemas que podem ocorrer ao executar notebooks manualmente. 


A equipe aumentou ainda mais a produtividade desenvolvendo um processo 
de CI/CD. “Ao conectar nosso reposit6rio de cédigo de controle de origem, 
sabemos que 0 fluxo de trabalho sempre executa a versdo de cédigo mais 
recente com a qual é feita o commit no repositério”, explica Zhang. “Também 

é facil mudar para um branch de desenvolvimento para desenvolver um novo 
recurso, corrigir um bug e executar um fluxo de trabalho de desenvolvimento. 
Quando o cédigo passa por todos os testes, é feito o merge de volta ao branch 
principal e o fluxo de trabalho de produgao é atualizado automaticamente com 
o codigo mais recente.” 


No futuro, a Wood Mackenzie planeja otimizar o uso dos fluxos de trabalho 

da Databricks para automatizar os processos de machine learning, como 
treinamento de modelos, monitoramento de modelos e manipulagaéo de drift 
de modelos. A empresa usa ML para melhorar a qualidade dos dados e extrair 
insights para agregar mais valor aos seus clientes. “Nossa missao é transformar 
a forma como alimentamos o planeta”, diz Wu. “Nossos clientes do setor 

de energia precisam de dados, consultoria e pesquisas para alcangar essa 
transformagao. O Databricks Workflows nos da a velocidade e a flexibilidade 
para fornecer os insights de que nossos clientes precisam.” 
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SETOR 
Manufatura 


SOLUGAO 

Manutengao preditiva, Dimensionamento 
de modelos de ML para loT, ESG orientada 
por dados 


PLATAFORMA 
Lakehouse, Delta Lake, Unity Catalog 


NUVEM 
AWS 
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SECGAO 4.5 
Rivian redefine a experiéncia de diregao 
com o Databricks Lakehouse 


250 usuarios da plataforma 


Aumento de 50x em relagao ao ano anterior 


A Rivian esta preservando o mundo natural para futuras geragées com os 
revoluciondrios veiculos elétricos de aventura (EAVs). Com mais de 25.000 EAVs em 
transito gerando varios terabytes de dados de loT por dia, aempresa esta usando 
insights de dados e machine learning para melhorar a integridade e o desempenho 

do veiculo. No entanto, com as ferramentas de cloud legadas, a empresa sofreu para 
escalar pipelines de forma econémica e gastou recursos significativos em manutengao, 
diminuindo sua capacidade de ser verdadeiramente orientada por dados. 


Desde que migrou para a Plataforma Databricks Lakehouse, a Rivian agora pode 
entender como um veiculo se comporta e como isso afeta o motorista que o utiliza. 
Equipada com esses insights, a Rivian esta inovando mais rapidamente, reduzindo 


custos e, em ultima analise, oferecendo uma melhor experiéncia de diregao aos clientes. 
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Sofrendo para democratizar os dados em 
uma plataforma legada 


Construir um mundo que continuara a ser desfrutado pelas geragodes futuras 
exige uma mudanga na forma como operamos. Na vanguarda desse movimento 
esta a Rivian, uma fabricante de veiculos elétricos focada em mudar os sistemas 
de energia e transporte do nosso planeta, abandonando por completo o 
combustivel féssil. Hoje, a frota da Rivian inclui veiculos pessoais e envolve 
uma parceria com a Amazon para entregar 100.000 vans comerciais. Cada 
veiculo usa sensores e cameras de loT para capturar petabytes de dados, 
desde a condugao do veiculo até o funcionamento de varias pegas. Com todos 
esses dados na ponta dos dedos, a Rivian usa machine learning para melhorar 
a experiéncia geral do cliente com a manutengao preditiva, de modo que os 
possiveis problemas sejam resolvidos antes que afetem o motorista. 


Antes mesmo de a Rivian langar seu primeiro EAV, ela ja enfrentava limitagées 
de visibilidade de dados e ferramentas que diminuiam a produgao, impediam 
a colaboragao e aumentavam os custos operacionais. Eles tinham de 30 a 50 
clusters de compute grandes e operacionalmente complicados a qualquer 
momento, 0 que saia caro. Além de ser dificil gerenciar o sistema, a empresa 
também sofria interrupgdes frequentes de cluster, forgando as equipes a 
dedicar mais tempo a solugao de problemas do que a analise de dados. Alem 
disso, os silos de dados criados por sistemas desarticulados desaceleraram o 
compartilhamento de dados, o que contribuiu ainda mais para problemas de 
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produtividade. As linguagens de dados necessarias e a experiéncia especifica 
dos conjuntos de ferramentas criaram uma barreira a entrada que limitou os 
desenvolvedores de fazer pleno uso dos dados disponiveis. Jason Shiverick, 
principal cientista de dados da Rivian, disse que 0 maior problema era 0 acesso 
aos dados. “Eu queria abrir nossos dados para um publico mais amplo de 
usuarios menos técnicos para que eles também pudessem aproveitar os dados 
com mais facilidade.” 


A Rivian sabia que, uma vez que seus EAVs chegassem ao mercado, a 
quantidade de dados ingeridos explodiria. Para oferecer a confiabilidade e 

o desempenho prometidos, a Rivian precisava de uma arquitetura que nao 
apenas democratizasse 0 acesso aos dados, mas também fornecesse uma 
plataforma comum para criar solugées inovadoras que ajudassem a garantir 
uma experiéncia de diregao confiavel e agradavel. 


O Databricks Lakehouse nos permite reduzir a barreira de 
entrada para 0 acesso aos dados em toda a nossa organizagao. 
Com isso, podemos construir os veiculos elétricos mais 


inovadores e confiaveis do mundo. 


Wassym Bensaid 
vice-presidente de desenvolvimento de software, Rivian 
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Previsao de problemas de manutengao com 
o Databricks Lakehouse 


A Rivian optou por modernizar sua infraestrutura de dados na Plataforma 
Databricks Lakehouse, oferecendo a capacidade de unificar todos os seus 
dados em uma visao comum para analise downstream e machine learning. 
Agora, equipes de dados exclusivas tém diversas ferramentas acessiveis 

para fornecer insights acionaveis para diferentes casos de uso, desde 
manutengao preditiva até desenvolvimento de produto mais inteligente. Venkat 
Sivasubramanian, diretor sénior de Big Data da Rivian, afirma: “Conseguimos 
construir uma cultura em torno de uma plataforma de dados abertos que 
fornecesse um sistema para realmente democratizar dados e analises de 
forma eficiente”. O suporte flexivel do Databricks a todas as linguagens de 
programagao e€ a integragao perfeita com uma variedade de conjuntos de 
ferramentas eliminaram os obstaculos de acesso e desbloquearam novas 
oportunidades. Wassym Bensaid, vice-presidente de desenvolvimento de 
software da Rivian, explica: “Hoje temos varias equipes, técnicas e de negécios, 
que usam o Databricks Lakehouse para explorar nossos dados, construir 
pipelines de dados de desempenho e extrair insights acionaveis de negdécios e 
produtos por meio de dashboards visuais”. 


A equipe de ADAS (sistemas avangados de assisténcia ao condutor) da Rivian 
agora pode preparar facilmente dados de aceler6metro telemétrico para 
entender todas as movimentagoes dos EAVs. Esses dados de gravagao central 
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incluem informag6ées sobre atividades de inclinagao, rotagao, velocidade, 
suspensao e airbag, para ajudar a Rivian a compreender o desempenho 

do veiculo, os padrées de diregao e a previsibilidade do sistema do carro 
conectado. Com base nessas métricas de desempenho importantes, a Rivian 
pode melhorar a precisao dos recursos inteligentes e o controle dos motoristas 
sobre eles. Projetados para aliviar o estresse de longas viagens e de dirigir em 
transito intenso, recursos como controle de cruzeiro adaptativo, assisténcia 
para mudanga de faixa, diregao automatica de emergéncia e aviso de colisao 
frontal podem ser aperfeigoados com o tempo para otimizar continuamente a 
experiéncia de diregao para os clientes. 


O compartilhamento e a colaboragao de dados seguros também foram 
facilitados com o Unity Catalog da Databricks. Shiverick descreve como a 
governanga unificada para o lakehouse beneficia a produtividade da Rivian. “O 
Unity Catalog nos oferece um catalogo de dados verdadeiramente centralizado 
em todas as nossas diferentes equipes”, disse ele. “Agora temos gerenciamento 
e controles de acesso adequados.” Venkat acrescenta: “Com o Unity Catalog, 
estamos centralizando o catalogo de dados e 0 gerenciamento de acesso em 
varias equipes e workspaces, 0 que simplificou a governanga”. A governanga 
controlada por versao de ponta a ponta e a auditabilidade de fontes de dados 
confidenciais, como as usadas para sistemas de diregao aut6noma, produzem 
uma solugao simples e segura para engenharia de recursos. Isso da a Rivian uma 
vantagem competitiva na corrida para capturar a rede de diregao aut6noma. 
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Acelerando em um mundo eletrificado e sustentavel 


Ao expandir sua capacidade de fornecer insights de dados valiosos com 
velocidade, eficiéncia e economia, a Rivian esta preparada para usar mais 
dados a fim de melhorar as operagdes e 0 desempenho de seus veiculos para 
aprimorar a experiéncia do cliente. Venkat diz: “A flexibilidade que o lakehouse 
oferece nos economiza muito dinheiro do ponto de vista da nuvem, e isso é 
uma grande vit6ria para nds.” Uma vez que o Databricks Lakehouse fornece 
uma abordagem unificada e de cédigo aberto para dados e analises, a equipe 
de confiabilidade do veiculo consegue entender melhor como as pessoas usam 
seus veiculos, e isso ajuda a definir o design das futuras geragées de veiculos. 
Ao usar a Plataforma Databricks Lakehouse, eles observaram um aumento de 
30% a 50% no desempenho do tempo de execugao, 0 que levou a insights mais 
rapidos e ao desempenho do modelo. 


Shiverick explica: “Do ponto de vista da confiabilidade, podemos garantir que 
os Componentes resistirao aos ciclos de vida apropriados. Pode ser tao simples 
quanto certificar-se de que as macanetas das portas sao robustas o suficiente 
para suportar o uso constante ou tao complicado quanto a manutengao 
preditiva e preventiva para eliminar a chance de falha no campo. De um modo 
geral, estamos melhorando a qualidade do software com base nas principais 
métricas do veiculo para uma melhor experiéncia do cliente.” 
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Do ponto de vista da otimizagao de design, a visao de dados desobstruida 

da Rivian também esta produzindo novos insights de diagnéstico que podem 
melhorar a satde, a seguranga, a estabilidade e a seguranga da frota. Venkat diz: 
“Podemos realizar diagnésticos remotos para fazer a triagem de um problema 
rapidamente, chamar um atendimento mével ou potencialmente enviar uma OTA 
para corrigir o problema com o software. Tudo isso precisa de muita visibilidade 
dos dados, e isso tem sido possivel com nossa parceria e integragao na prdépria 
plataforma.” Os desenvolvedores constroem ativamente o software do veiculo 
para melhorar os problemas ao longo do caminho. 


Seguindo em frente, a Rivian esta vendo rapida adogao do Databricks Lakehouse 
em diferentes equipes, aumentando o numero de usuarios da plataforma de 5 
para 250 em apenas um ano. Isso desbloqueou novos casos de uso, incluindo o 
uso de machine learning para otimizar a eficiéncia da bateria em temperaturas 
mais frias, aumentar a precisao dos sistemas de diregaéo aut6noma e atender a 
depdsitos comerciais com dashboards de satide do veiculo para manutengao 
precoce e continua. A medida que mais EAVs sao enviados e sua frota de vans 
comerciais se expande, a Rivian continuara a aproveitar os dados gerados 

por seus EAVs para oferecer novas inovagées e experiéncias de diregao que 
revolucionam o transporte sustentavel. 
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SETOR 
Provedores de servigos de comunicagao 


SOLUGAO 
Retengao de clientes, Previsaéo de perda 
de assinatura, Detecgao de ameagas 


PLATAFORMA 
Lakehouse, Data science, Machine learning, 
Streaming de dados 


NUVEM 
Azure 
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SECAO 4.6 
Migragao para a nuvem para atender melhor 
a milhoes de clientes 


300% 3X 


ROI da economia de custos Entrega mais rapida de casos 
operacionais e redugao de custos de uso de ML/data science 


Consisténcia em inovagao € o que mantém os clientes com uma empresa de telecomunicagées, 
e € por isso que a AT&T esta entre as melhores. No entanto, o enorme sistema Hadoop legado 
local da AT&T acabou sendo complexo e dispendioso de gerenciar, impedindo a agilidade 
operacional e a eficiéncia e os recursos de engenharia. A necessidade de mudar para a nuvem 
para oferecer melhor suporte a centenas de milhées de assinantes era dbvia. 


Ao migrar do Hadoop para o Databricks na nuvem Azure, a AT&T teve economias significativas 
nos custos operacionais. Além disso, o novo ambiente baseado na nuvem desbloqueou o acesso 
a petabytes de dados para analise correlativa e uma oferta de IA como servigo para mais de 
2.500 usuarios em mais de 60 unidades de negocios. A AT&T agora pode aproveitar todos os 
seus dados, sem sobrecarregar sua equipe de engenharia ou estourar os custos operacionais, 
para fornecer novos recursos e inovagées aos milhdes de usuarios finais. 
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A tecnologia Hadoop adiciona complexidade operacional 
e custos desnecessarios 


A AT&T € uma gigante da tecnologia, com centenas de milhdes de assinantes 

e ingere mais de 10 petabytes|a] de dados em toda a plataforma de dados 
todos os dias. Para aproveitar esses dados, ela tem uma equipe de mais de 
2.500 usuarios de dados em mais de 60 unidades de negocios para garantir 
que os negécios sejam baseados em dados — da criagao de fungées analiticas 
para garantir que as decisOes sejam baseadas na melhor conscientizagao 

da situagao orientada por dados a criagao de modelos de ML que trazem 
inovagées para seus clientes. Para atender a esses requisitos, a AT&T precisava 
democratizar e estabelecer uma versdo Unica da verdade (SVOT) dos dados e, 
ao mesmo tempo, simplificar o gerenciamento da infraestrutura para aumentar 
a agilidade e reduzir os custos gerais. 


No entanto, a infraestrutura fisica consumia muitos recursos. A combinagao de 
uma configuragao de hardware altamente complexa (12.500 fontes de dados e 
mais de 1.500 servidores) com uma arquitetura Hadoop on-premises se mostrou 
complexa de manter e cara de gerenciar. Nao apenas os custos operacionais 
para dar suporte as cargas de trabalho eram altos, mas também havia custos 

de capital adicionais relacionados a data centers, licenciamento e outros. Até 


70% da plataforma on-prem precisava ser priorizada para garantir que 50 mil 

jobs de pipeline de dados fossem bem-sucedidos e atendessem aos SLAs e aos 
objetivos de qualidade de dados. O tempo dos engenheiros era concentrado no 
gerenciamento de atualizagdes, na corregao de problemas de desempenho ou 
simplesmente no provisionamento de recursos, e nado em tarefas de maior valor. As 
restrigdes de recursos da infraestrutura fisica também levaram a serializagao das 
atividades de data science, retardando a inovagaéo. Outro obstaculo enfrentado na 
operacionalizagao de petabytes de dados foi 0 desafio de criar pipelines de dados 
de streaming para analise em tempo real, uma area que era fundamental para dar 


suporte a casos de uso inovadores necessarios para atender melhor aos clientes. 
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Com esses problemas tecnolégicos profundamente enraizados, a AT&T nao 
estava na melhor posigao para atingir suas metas de aumentar o uso de 
insights para melhorar a experiéncia do cliente e operar com mais eficiéncia. 
“Para realmente democratizar os dados em toda a empresa, precisavamos 
migrar para um ambiente de tecnologia nativa em nuvem”, disse Mark Holcomb, 
arquiteto de solugées da AT&T. “Isso liberou os recursos que estavam focados 
no gerenciamento da nossa infraestrutura e moveu-os para cima na cadeia de 
valor, além de ter liberado capital para investir em iniciativas voltadas para 

o crescimento.” 


Uma jornada de migragao perfeita para a Databricks 


Como parte de sua due diligence, a AT&T realizou uma analise de custos 
abrangente e concluiu que a Databricks foi a mais rapida e alcangou o melhor 
prego/desempenho para pipelines de dados e cargas de trabalho de machine 
learning. A AT&T sabia que a migragao seria uma tarefa enorme. Como tal, a 
equipe fez muito planejamento inicial — eles priorizaram a migragao de suas 
maiores cargas de trabalho primeiro para reduzir imediatamente a area de 
cobertura de infraestrutura. Também decidiram migrar seus dados antes de 
migrar os usuarios para garantir uma transigado e experiéncia tranquilas para 
seus milhares de profissionais de dados. 


A migragao do Hadoop para o Databricks nos permite agregar 
mais valor aos nossos clientes e fazer isso de forma mais 
econdémica e muito mais rapida do que antes. 


Mark Holcomb 
arquiteto de solugées, AT&T 


O livro completo da engenharia de dados — 2° Edi¢gao 


Eles passaram um ano desduplicando e sincronizando dados na nuvem antes 
de migrar qualquer usuario. Essa foi uma etapa fundamental para garantir a 
migragao bem-sucedida de um ambiente multi-tenant tao grande e complexo 
de mais de 2.500 usuarios de mais de 60 unidades de negocios e de suas 
cargas de trabalho. O processo de migragao dos usuarios ocorreu ao longo 

de nove meses e permitiu que a AT&T retirasse o hardware on-premises em 
paralelo com a migragao para acelerar a economia o mais rapido possivel. 
Além disso, devido a natureza horizontal e escalavel da Databricks, a AT&T nao 
precisava ter tudo em um ambiente contiguo. Separar dados e compute, e em 
varias contas e workspaces, garantiu que a analise funcionasse perfeitamente, 
sem limites de chamadas de API ou problemas de largura de banda e consumo 
claramente atribuidos as mais de 60 unidades de negocios. 


Em suma, a AT&T migrou mais de 1.500 servidores, mais de 50.000 CPUs de 
produgao, 12.500 fontes de dados e 300 esquemas. Todo 0 processo levou 
cerca de dois anos e meio. E ainda conseguiu gerenciar toda a migragao com 

o equivalente a 15 recursos internos em tempo integral. “A Databricks foi uma 
valiosa colaboradora durante todo o processo”, disse Holcomb. “A equipe 
trabalhou em estreita colaboragao conosco para resolver os recursos do produto 
e as preocupacoes de seguranga para dar suporte ao nosso cronograma 

de migragao.” 


Databricks reduz o TCO e abre novos caminhos 
para a inovagao 


Um dos beneficios imediatos de migrar para a Databricks foi a enorme 
economia de custos. A AT&T conseguiu racionalizar cerca de 30% de seus 
dados identificando e nao migrando dados subutilizados e duplicados. E 
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priorizar a migragao das maiores cargas de trabalho permitiu que metade do 
equipamento on-prem fosse racionalizado durante a migragao. “Ao priorizar 

a migragado de nossas cargas de trabalho mais intensivas em compute para a 
Databricks, conseguimos reduzir significativamente os custos, ao mesmo tempo 
que nos colocamos em posigao de escalar com mais eficiéncia no futuro”, 
explicou Holcomb. O resultado € um ROI de migragao de cinco anos previsto de 
300% a partir da economia de despesas operacionais e da redugaéo de custos 
(por exemplo, nao é necessario atualizar o hardware do data center). 


Com os dados prontamente disponiveis e os meios para analisar os dados 

em qualquer escala, as equipes de data scientists e analistas de dados dos 
cidadaos agora podem passar mais tempo inovando, em vez de serializar 

os esforgos de analise ou esperar que a engenharia fornega os recursos 
necessarios, ou fazer com que os data scientists gastem seu valioso tempo em 
analises menos complexas ou menos perspicazes. Os data scientists agora sao 
Ccapazes de colaborar de forma mais eficaz e acelerar os fluxos de trabalho de 
machine learning para que as equipes possam entregar valor mais rapidamente, 
com um tempo 3 vezes mais rapido para a entrega de novos casos de uso de 
data science. 


“Historicamente, teriamos tido operagdes em um sistema e analises em um 
sistema separado”, disse Holcomb. “Agora podemos fazer mais casos de uso, 
como analises operacionais, em uma plataforma que promove a colaboragao 
entre equipes, reduz custos e melhora a consisténcia das respostas.” Desde a 
migragao para a Databricks, a AT&T agora tem uma versao unica da verdade para 
criar novas oportunidades orientadas por dados, incluindo uma plataforma de 
analise self-service de IA como servigo que permitira novos fluxos de receita e 
ajudara a continuar oferecendo inovagédes excepcionais aos milhdées de clientes. 


Sobre a Databricks 


Databricks € a empresa de dados e IA. Mais de 10.000 organizagées 
em todo 0 mundo — incluindo Comcast, Condé Nast e mais de 50% 
das empresas Fortune 500 — contam com a Plataforma Databricks 
Lakehouse para unificar seus dados, analises e IA. A Databricks 


esta sediada em Sao Francisco, com escritérios em todo 0 mundo. 
Fundada pelos criadores originais do Apache Spark™, Delta Lake e 
MLflow, a Databricks tem a missao de ajudar as equipes de dados a 
resolver os problemas mais dificeis do mundo. Para saber mais, siga 


a Databricks no : e 
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